Sungrow SH15T. Issues with reading home battery data

Describe the bug
Evcc cannot read home battery data while using "sungrow-hybrid" template.
The inverter SH15T, communication device Winet-S2, and the Battery SBR128 are updated to the latest firmware.
The inverter is connected via the LAN port on the Winet-S2 dongle.

Still, the invertor data is shown on another dashboard and there the Battery data is shown:

Steps to reproduce
Restart the Evcc
Configuration details
interval: 30s # control cycle interval

log: debug
levels:
  cache: error

modbusproxy:
  port: 5021
  uri: <IP_ADDRESS>:502

meters:
  - name: grid1
    type: template
    template: sungrow-hybrid
    usage: grid
    modbus: tcpip
    id: 1
    host: <IP_ADDRESS> # Hostname
    port: 502 # Port
    timeout: 30s # optional for modbus: tcpip?

  - name: pv2
    type: template
    template: sungrow-hybrid
    usage: pv
    modbus: tcpip
    id: 1
    host: <IP_ADDRESS> # Hostname
    port: 502 # Port
    timeout: 30s # optional for modbus: tcpip

  - name: battery3
    type: template
    template: sungrow-hybrid
    usage: battery
    modbus: tcpip
    id: 1
    host: <IP_ADDRESS> # Hostname
    port: 502 # Port
    capacity: 12.8 # Akkukapazität in kWh (optional)
    timeout: 30s # optional for modbus: tcpip

chargers:
  - type: template
    template: twc3
    host: <IP_ADDRESS>
    name: teslaCharger

vehicles:
  - name: teslay
    type: template
    template: tesla
    title: Tesla Y
    icon: car
    vin: xxxxx
    capacity: 59
    phases: 3
    accessToken: xxxxx
    refreshToken: xxxxx
    commandProxy: xxxxx

loadpoints:
  - title: Garage
    charger: teslaCharger
    mode: pv
    #  resetOnDisconnect: true
    vehicle: teslay

site:
  title: HomeSweetHome
  meters:
    grid: grid1
    pv:
      - pv2
    battery:
      - battery3
  residualPower: 100
  maxGridSupplyWhileBatteryCharging: 50
#  batteryDischargeControl: true

tariffs:
  currency: EUR # (default EUR)
  grid:
    type: tibber
    token: xxxxx
    homeid: xxxxx

  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.082 # [currency]/kWh
  co2:
    type: grünstromindex
    zip: xxxxx

Log details
[site  ] DEBUG 2024/10/17 20:17:53 ----
[twc3  ] TRACE 2024/10/17 20:17:53 GET http://<IP_ADDRESS>/api/1/vitals
[twc3  ] TRACE 2024/10/17 20:17:53 {"contactor_closed":false,"vehicle_connected":true,"session_s":10085,"grid_v":236.8,"grid_hz":49.782,"vehicle_current_a":0.4,"currentA_a":0.2,"currentB_a":0.4,"currentC_a":0.0,"currentN_a":0.2,"voltageA_v":0.0,"voltageB_v":0.0,"voltageC_v":1.1,"relay_coil_v":11.8,"pcba_temp_c":21.3,"handle_temp_c":17.9,"mcu_temp_c":28.1,"uptime_s":152263,"input_thermopile_uv":-259,"prox_v":0.0,"pilot_high_v":8.7,"pilot_low_v":-11.7,"session_energy_wh":262.800,"config_status":5,"evse_state":4,"current_alerts":[],"evse_not_ready_reasons":[1]}
[lp-1  ] DEBUG 2024/10/17 20:17:53 charge power: 0W
[lp-1  ] DEBUG 2024/10/17 20:17:53 charge currents: [0.2 0.4 0]A
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 af 00 00 00 06 01 04 32 d1 00 02
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 af 00 00 00 07 01 04 04 00 00 00 00
[site  ] DEBUG 2024/10/17 20:17:53 grid power: -0W
[pv2   ] TRACE 2024/10/17 20:17:53 modbus: send 38 b0 00 00 00 06 01 04 13 98 00 02
[pv2   ] TRACE 2024/10/17 20:17:53 modbus: recv 38 b0 00 00 00 07 01 04 04 00 00 00 00
[pv2   ] TRACE 2024/10/17 20:17:53 modbus: send 38 b1 00 00 00 06 01 04 32 ca 00 02
[pv2   ] TRACE 2024/10/17 20:17:53 modbus: recv 38 b1 00 00 00 07 01 04 04 10 de 00 00
[site  ] DEBUG 2024/10/17 20:17:53 pv power: 0W
[battery3] TRACE 2024/10/17 20:17:53 modbus: send 38 b2 00 00 00 06 01 04 32 dd 00 01
[battery3] TRACE 2024/10/17 20:17:53 modbus: recv 38 b2 00 00 00 05 01 04 02 05 1c
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 b3 00 00 00 06 01 04 15 e2 00 02
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 b3 00 00 00 07 01 04 04 fe b8 ff ff
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 b4 00 00 00 06 01 04 13 9a 00 01
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 b4 00 00 00 05 01 04 02 09 61
[battery3] TRACE 2024/10/17 20:17:53 modbus: send 38 b5 00 00 00 06 01 04 32 c8 00 01
[battery3] TRACE 2024/10/17 20:17:53 modbus: recv 38 b5 00 00 00 05 01 04 02 00 00
[battery3] TRACE 2024/10/17 20:17:53 modbus: send 38 b6 00 00 00 06 01 04 32 c8 00 01
[battery3] TRACE 2024/10/17 20:17:53 modbus: recv 38 b6 00 00 00 05 01 04 02 00 00
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 b7 00 00 00 06 01 04 15 e4 00 02
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 b7 00 00 00 07 01 04 04 02 2e 00 00
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 b8 00 00 00 06 01 04 13 9b 00 01
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 b8 00 00 00 05 01 04 02 09 4d
[battery3] TRACE 2024/10/17 20:17:53 modbus: send 38 b9 00 00 00 06 01 04 32 e2 00 02
[battery3] TRACE 2024/10/17 20:17:53 modbus: recv 38 b9 00 00 00 07 01 04 04 01 23 00 00
[battery3] TRACE 2024/10/17 20:17:53 modbus: send 38 ba 00 00 00 06 01 04 32 de 00 01
[battery3] TRACE 2024/10/17 20:17:53 modbus: recv 38 ba 00 00 00 05 01 04 02 02 f3
[site  ] DEBUG 2024/10/17 20:17:53 battery soc: 76%
[site  ] DEBUG 2024/10/17 20:17:53 battery power: 0W
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 bb 00 00 00 06 01 04 15 e6 00 02
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 bb 00 00 00 07 01 04 04 ff 29 ff ff
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 bc 00 00 00 06 01 04 13 9c 00 01
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 bc 00 00 00 05 01 04 02 09 47
[site  ] DEBUG 2024/10/17 20:17:53 grid currents: [-1.37 2.34 -0.905]A
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: send 38 bd 00 00 00 06 01 04 32 ec 00 02
[grid1 ] TRACE 2024/10/17 20:17:53 modbus: recv 38 bd 00 00 00 07 01 04 04 14 49 00 00
[site  ] DEBUG 2024/10/17 20:17:53 site power: 100W
[lp-1  ] DEBUG 2024/10/17 20:17:53 charge voltages: [0 0 1.1]V
[lp-1  ] DEBUG 2024/10/17 20:17:53 charger status: B
[tesla ] TRACE 2024/10/17 20:17:53 GET https://fleet-api.prd.eu.vn.cloud.tesla.com/api/1/vehicles/LRWYGCFSXPC742839/vehicle_data
[tesla ] TRACE 2024/10/17 20:17:54 {"response":null,"error":"vehicle unavailable: vehicle is offline or asleep","error_description":"","txid":"8cd7c097efa03cafbc6d94e18cf5a0a1"}
[lp-1  ] DEBUG 2024/10/17 20:17:54 pv charge current: 0A = 0A + -0.145A (100W @ 3p)
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5007 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 01d2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5010 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 00dc
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5011 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5012 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 01f5
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5013 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5016 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 00000000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5018 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0961
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5019 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 094d
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5020 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 093b
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5032 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 00000000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5034 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 03e7
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5241 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: modbus: exception '0' (unknown), function '4'
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5600 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 000e0000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5602 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: feb8ffff
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5604 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 022e0000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5606 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: ff29ffff
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5725 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 00000000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5722 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: fffe
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5723 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0005
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5724 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: ffff
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5740 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: modbus: exception '0' (unknown), function '4'
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5741 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: modbus: exception '0' (unknown), function '4'
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5742 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: modbus: exception '0' (unknown), function '4'
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5743 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: modbus: exception '0' (unknown), function '4'
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5744 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: modbus: exception '0' (unknown), function '4'
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 5745 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: modbus: exception '0' (unknown), function '4'
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 12999 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 8200
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13000 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13007 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 04de0000
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13009 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: ffe6ffff
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13019 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0a56
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13020 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0030
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13021 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 051c
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13030 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0015
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13031 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0015
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13032 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 0015
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: id 1 addr 13033 qty 2
[proxy-5021] TRACE 2024/10/17 20:17:54 read input: 04c40000
[proxy-5021] TRACE 2024/10/17 20:17:54 read holdings: id 1 addr 12999 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read holding: 00cf
[proxy-5021] TRACE 2024/10/17 20:17:54 read holdings: id 1 addr 13049 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:54 read holding: 0000
[proxy-5021] TRACE 2024/10/17 20:17:54 read holdings: id 1 addr 13050 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:55 read holding: 00cc
[proxy-5021] TRACE 2024/10/17 20:17:55 read holdings: id 1 addr 13051 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:55 read holding: 0000
[proxy-5021] TRACE 2024/10/17 20:17:55 read holdings: id 1 addr 13057 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:55 read holding: 03e8
[proxy-5021] TRACE 2024/10/17 20:17:55 read holdings: id 1 addr 13058 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:56 read holding: 0064
[proxy-5021] TRACE 2024/10/17 20:17:56 read holdings: id 1 addr 13073 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:56 read holding: 024e
[proxy-5021] TRACE 2024/10/17 20:17:56 read holdings: id 1 addr 13086 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:56 read holding: 00aa
[proxy-5021] TRACE 2024/10/17 20:17:56 read holdings: id 1 addr 13099 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:56 read holding: 0005
[proxy-5021] TRACE 2024/10/17 20:17:56 read holdings: id 1 addr 33046 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:57 read holding: 02bc
[proxy-5021] TRACE 2024/10/17 20:17:57 read holdings: id 1 addr 33047 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:57 read holding: 02bc
[proxy-5021] TRACE 2024/10/17 20:17:57 read holdings: id 1 addr 33148 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:57 read holding: ffff
[proxy-5021] TRACE 2024/10/17 20:17:57 read holdings: id 1 addr 33149 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:57 read holding: ffff
[proxy-5021] TRACE 2024/10/17 20:17:57 read holdings: id 1 addr 30229 qty 1
[proxy-5021] TRACE 2024/10/17 20:17:57 read holding: 0055
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5007 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 01d2
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5010 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 00dc
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5011 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 0000
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5012 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 01f5
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5013 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 0000
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5016 qty 2
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 00000000
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5018 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 0965
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5019 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 0949
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5020 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 0940
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5032 qty 2
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 00000000
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5034 qty 1
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: 03e7
[proxy-5021] TRACE 2024/10/17 20:18:04 read input: id 1 addr 5241 qty 1

What type of operating system are you running?
HomeAssistant Add-on
Nightly build

[X] I have verified that the issue is reproducible with the latest nightly build

Version
v0.130.13

Hi @andig ,
thank you for your fast response!
The first screenshot shows that the Battery SOC is 73% (which is correct), but the battery discharging is 0.0 w (which is not correct). In the second screenshot, it can be seen that the battery discharging 1.05 kW. In the EVCC logs can be seen that
[site  ] DEBUG 2024/10/17 20:17:53 battery power: 0W
I assume that the EVCC sungrow-hybrid template can not properly calculate the charging/discharging power of the battery.
Please let me know if additional info is needed.

Was sagt
evcc meter --log trace,db:error

Welche Werte stimmen nicht?

Lets see evcc meter please.

@andig
I have installed the Evcc on standalone linux server just for debugging and was able to pull the evcc meter logs
`[main  ] INFO 2024/10/18 15:15:24 evcc 0.130.13 (b313e3c5)
[main  ] INFO 2024/10/18 15:15:24 using config file: /etc/evcc.yaml
pv2
[pv2   ] TRACE 2024/10/18 15:15:24 modbus: send 00 01 00 00 00 06 01 04 13 98 00 02
[pv2   ] TRACE 2024/10/18 15:15:24 modbus: recv 00 01 00 00 00 07 01 04 04 01 ed 00 00
[pv2   ] TRACE 2024/10/18 15:15:24 modbus: send 00 02 00 00 00 06 01 04 32 ca 00 02
[pv2   ] TRACE 2024/10/18 15:15:24 modbus: recv 00 02 00 00 00 07 01 04 04 11 0f 00 00
Power:  493W
Energy: 436.7kWh
grid1
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 03 00 00 00 06 01 04 32 d1 00 02
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 03 00 00 00 07 01 04 04 00 00 00 00
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 04 00 00 00 06 01 04 32 ec 00 02
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 04 00 00 00 07 01 04 04 14 4a 00 00
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 05 00 00 00 06 01 04 15 e2 00 02
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 05 00 00 00 07 01 04 04 ff e3 ff ff
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 06 00 00 00 06 01 04 13 9a 00 01
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 06 00 00 00 05 01 04 02 09 56
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 07 00 00 00 06 01 04 15 e4 00 02
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 07 00 00 00 07 01 04 04 00 03 00 00
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 08 00 00 00 06 01 04 13 9b 00 01
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 08 00 00 00 05 01 04 02 09 43
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 09 00 00 00 06 01 04 15 e6 00 02
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 09 00 00 00 07 01 04 04 00 71 00 00
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: send 00 0a 00 00 00 06 01 04 13 9c 00 01
[grid1 ] TRACE 2024/10/18 15:15:24 modbus: recv 00 0a 00 00 00 05 01 04 02 09 4a
Power:          -0W
Energy:         519.4kWh
Current L1..L3: -0.121A 0.0127A 0.475A
battery3
[battery3] TRACE 2024/10/18 15:15:24 modbus: send 00 0b 00 00 00 06 01 04 32 dd 00 01
[battery3] TRACE 2024/10/18 15:15:24 modbus: recv 00 0b 00 00 00 05 01 04 02 00 91
[battery3] TRACE 2024/10/18 15:15:24 modbus: send 00 0c 00 00 00 06 01 04 32 c8 00 01
[battery3] TRACE 2024/10/18 15:15:24 modbus: recv 00 0c 00 00 00 05 01 04 02 00 00
[battery3] TRACE 2024/10/18 15:15:24 modbus: send 00 0d 00 00 00 06 01 04 32 c8 00 01
[battery3] TRACE 2024/10/18 15:15:24 modbus: recv 00 0d 00 00 00 05 01 04 02 00 00
[battery3] TRACE 2024/10/18 15:15:24 modbus: send 00 0e 00 00 00 06 01 04 32 e2 00 02
[battery3] TRACE 2024/10/18 15:15:24 modbus: recv 00 0e 00 00 00 07 01 04 04 01 6c 00 00
[battery3] TRACE 2024/10/18 15:15:24 modbus: send 00 0f 00 00 00 06 01 04 32 de 00 01
[battery3] TRACE 2024/10/18 15:15:24 modbus: recv 00 0f 00 00 00 05 01 04 02 00 f6
Power:        0W
Energy:       36.4kWh
Soc:          25%
Controllable: true
`
Battery 3 power is shown as 0, but actually is 129W

Battery power is the odd one:
  power:
    source: calc
    mul:
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        address: 13021 # Battery power 32DD
        type: input
        decode: int16
    - source: calc
      add:
      - source: modbus
        {{- include "modbus" . | indent 6 }}
        register:
          type: input
          address: 13000 # Battery running state 32C8
          decode: bool16
          bitmask: 2 # Charging
        scale: -1
      - source: modbus
        {{- include "modbus" . | indent 6 }}
        register:
          type: input
          address: 13000 # Battery running state 32C8
          decode: bool16
          bitmask: 4 # Discharging

From another Sungrow resource I see small difference in decode type for address 13021:
      - name: Battery power raw         unique_id: sg_battery_power_raw         device_address: !secret sungrow_modbus_slave         address: 13021 # reg 13022         input_type: input         data_type: uint16         precision: 0         unit_of_measurement: W         device_class: power         state_class: measurement         scale: 1         scan_interval: 10
      - name: Running state         unique_id: sg_running_state         device_address: !secret sungrow_modbus_slave         address: 13000 # reg 13001         input_type: input         data_type: uint16         precision: 0         state_class: measurement         scale: 1         scan_interval: 10
Could this be the reason?

That doesn't tell me anything.

@andig Thank you! Will check the docs and maybe some other open source materials.
I see that evcc users have a similar issue:
https://github.com/evcc-io/evcc/issues/15915

@andig solved my issue by changing the battery power calculation logic. I'm multiplying battery voltage with battery current (which comes with +/-) and having the power value needed by EVCC.
For this purpose, I created a separate template for my EVCC configuration.
power:
source: calc
mul:
- source: modbus
{{- include "modbus" . | indent 4 }}
register:
address: 13019 # Battery voltage
type: input
decode: int16
scale: 0.1
- source: modbus
{{- include "modbus" . | indent 4 }}
register:
address: 13020 # Battery current
type: input
decode: int16
scale: 0.1

Here is entire template in case someone will need it:
template: sungrow-sht-hybrid
covers: ["sungrow"]
products:
  - brand: Sungrow
    description:
      generic: SH Series Hybrid Inverter
capabilities: ["battery-control"]
requirements:
  description:
    de: Verbindungen über das WiNet-S-Dongle (WiFi oder LAN) funktionieren nur mit aktueller Firmware. Ältere Versionen liefern nicht alle benötigten Daten (Leistung, Ladestand).
    en: Connections via the WiNet-S dongle (WiFi or LAN) only work with the latest firmware. Older versions do not provide all required data (power, state of charge).
params:
  - name: usage
    choice: ["grid", "pv", "battery"]
    allinone: true
  - name: modbus
    choice: ["rs485", "tcpip"]
    baudrate: 9600
  - name: timeout
  - name: capacity
    advanced: true
render: |
  type: custom
  {{- if eq .usage "grid" }}
  power:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register:
      type: input
      address: 13009 # Export power
      decode: int32s
    scale: -1
  energy:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register:
      address: 13036 # Total Import Energy, 0.1kWh
      type: input
      decode: uint32s
    scale: 0.1
  currents:
  - source: calc
    div:
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        type: input
        address: 5602 # Meter Phase A Active Power, 1W
        decode: int32s
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        type: input
        address: 5018 # Phase A voltage, 0.1V
        decode: uint16
      scale: 0.1
  - source: calc
    div:
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        type: input
        address: 5604 # Meter Phase B Active Power, 1W
        decode: int32s
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        type: input
        address: 5019 # Phase b voltage, 0.1V
        decode: uint16
      scale: 0.1
  - source: calc
    div:
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        type: input
        address: 5606 # Meter Phase C Active Power, 1W
        decode: int32s
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        type: input
        address: 5020 # Phase C voltage, 0.1V
        decode: uint16
      scale: 0.1
  {{- end }}
  {{- if eq .usage "pv" }}
  power:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register:
      address: 5016 # Total DC power
      type: input
      decode: uint32s
  energy:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register:
      address: 13002 # Total PV Generation, 0.1kWh
      type: input
      decode: uint32s
    scale: 0.1
  {{- end }}
  {{- if eq .usage "battery" }}
  power:
    source: calc
    mul:
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        address: 13019 # Battery voltage
        type: input
        decode: int16
      scale: 0.1
    - source: modbus
      {{- include "modbus" . | indent 4 }}
      register:
        address: 13020 # Battery current
        type: input
        decode: int16
      scale: 0.1
  energy:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register:
      address: 13026 # Total battery discharge energy, 0.1kWh
      type: input
      decode: uint32s
    scale: 0.1
  soc:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register:
      address: 13022 # Battery level
      type: input
      decode: int16
    scale: 0.1
  batterymode:
    source: switch
    switch:
    - case: 1 # normal
      set:
        source: sequence
        set:
        - source: const
          value: 0 # Self-consumption mode (Default)
          set:
            source: modbus
            {{- include "modbus" . | indent 10 }}
            timeout: {{ .timeout }}
            register:
              address: 13049 # EMS mode selection
              type: writesingle
              decode: uint16
        - source: const
          value: 0xCC # Stop (Default)
          set:
            source: modbus
            {{- include "modbus" . | indent 10 }}
            timeout: {{ .timeout }}
            register:
              address: 13050 # Charge/discharge command
              type: writesingle
              decode: uint16
    - case: 2 # hold
      set:
        source: sequence
        set:
        - source: const
          value: 2 # Forced mode (charge/discharge/stop)
          set:
            source: modbus
            {{- include "modbus" . | indent 10 }}
            timeout: {{ .timeout }}
            register:
              address: 13049 # EMS mode selection
              type: writesingle
              decode: uint16
        - source: const
          value: 0xCC # Stop (Default)
          set:
            source: modbus
            {{- include "modbus" . | indent 10 }}
            timeout: {{ .timeout }}
            register:
              address: 13050 # Charge/discharge command
              type: writesingle
              decode: uint16
    - case: 3 # charge
      set:
        source: sequence
        set:
        - source: const
          value: 2 # Forced mode (charge/discharge/stop)
          set:
            source: modbus
            {{- include "modbus" . | indent 10 }}
            timeout: {{ .timeout }}
            register:
              address: 13049 # EMS mode
              type: writesingle
              decode: uint16
        - source: const
          value: 0xAA # Charge
          set:
            source: modbus
            {{- include "modbus" . | indent 10 }}
            timeout: {{ .timeout }}
            register:
              address: 13050 # Charge/discharge command
              type: writesingle
              decode: uint16
        - source: go
          script: power
          in:
          - name: power
            type: int
            config:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              timeout: {{ .timeout }}
              register:
                address: 5627 # BDC rated power
                type: input
                decode: uint16
              scale: 100
          out:
          - name: power
            type: int
            config:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              timeout: {{ .timeout }}
              register:
                address: 13051 # Charge/discharge power
                type: writesingle
                decode: uint16
  capacity: {{ .capacity }} # kWh
  {{- end }}
`

Sehr cool. Magst Du einen PR dafür machen? Vielen Dank!

You can open a PR without any permissions!
In terms of scope: is the battery power the only change? Then the implementation could use the current template and add a switch Plugin. One case for 13000 && (Discharge || Charge) being 0 (the change here) and a default case for the current solution.
I'd still appreciate a ticket with Sungrow. evcc has implemented the interface as per Modbus documentation. Inverter does not seem to follow that.

Our documentation is TI_20211231_Communication Protocol of Residential Hybrid Inverter_V1.0.23_EN from 2022. If anybody has more recent version that might help too.

Here is entire template in case someone will need it:

hi @leonidrm ich habe das gleiche Issue und such schon ein paar wochen nach einer lösung...
Daher will ich da unbeding testen :-)
Wo kopierts du deinen yaml code genau rein?
in das evcc.yaml?

@wapman1979 Unfortunately right now is a little bit more complicated. You need either to edit the templates/definition/meter/sungrow-hybrid.yaml from evcc repository and rebuild the app, either to create a separate template in templates/definition/meter/ directory and use it later in evcc.yaml configuration.
This week I'll try to find a little time and will create a PR to Evcc repository and then the fix will come to everyone just by updating the application to latest version.

Here's the diff of the two templates:

I would really like to avoid duplicating everything else. Could you please add the SHT modbus documentation here so we can take a look how to auto-switch if possible?

Hi,
I have also the same problem and interested in the PR.
I am not familiar with the modbus protocol and a newbie with my 1 week old PV 😉
But I found a new "version" of the specification; perhaps this will help:
Communication Protocol of Residential Hybrid Inverter-V1.1.4.pdf

@Afrouper Thank you for the updated documentation. This explains everything!
@andig  Sungrow changed the running state to power flows (point 11). We should change the address from 13000 to 13001

I have tried to push the branch and make a PR but I'm getting a permission error:

@andig can you please change the address from sungrow-hybrid.yaml:123 and 131 to 13001?

Thanks.
@leonidnf You should (and cannot) not push direct to the evcc projects master. I think you have to create a fork of the evcc repo. In this fork you can make the changes and then create a PR to the evcc project.
@andig Should this Issue be still open and not closed?
Thanks Christian

@andig can you please change the address from sungrow-hybrid.yaml:123 and 131 to 13001?

Hi @leonidnf,
thanks to time change this night I have some time to read the specifications. I think that sungrow did not do some breaking changes - they only do some renaming and did not change the meanings of the address. So the configured address 13000 seems to be correct because the addresses started at 1 and not 0; so you have to add 1 to the configured addresses in der YAML file.
(No garantee - AI helped me with this stuff 😇)
Please double check. Might there be a fault in the sungrow implementation?

Hi @Afrouper,
Unfortunately, I'm not an expert in Modbus, but I have general understanding how this works. Currently, my setup works on an evcc-fork that uses battery-current and battery-voltage to calculate the battery-power.
Now I'm testing 13001 and it gives same results.
In this screenshot we have results for 13000 address. The battery-power can not be calculated and its value is shown as 0:

In following screenshot we have results for 13001 address. The battery-power was able to be calculated and we see a  value of -231W

Sungrow has documented a change to 13000/13001 but totally fails to mention which devices this applies to. Could someone please contact Sungrow and ask how to detect which register is correct? It MUST be clear from outside without guessing. At least that would be my hope…

Could someone please contact Sungrow and ask how to detect which register is correct?

I just created service request CL2410270267 in the sungrow portal - hope I get an answer.
But an additional question...
According to appendix "4.2 Power Flow Status" it is the same as in the older documentation ("Appendix 1.2 Running state"). For me it sounds like they just renamed "Battery maintenance" to "Power Flow Status" - the address 13001 is still the same.
@andig Just for my understanding. When writing 13000 in the sungrow-hybrid.yaml evcc will access modbus address "13001", correct? As I understand there is an offset of 1.
With this in mind all other addresses in sungrow-hybrid.yaml seems to be correct.
@leonidrm Thanks for testing - looks good. Are you sure the when reading from 13001 you do not get data from "Daily PV Generation"?
Thanks and sorry if I am totally wrong with the meanings from modbus and the addresses.

@andig Just for my understanding. When writing 13000 in the sungrow-hybrid.yaml evcc will access modbus address "13001", correct? As I understand there is an offset of 1.

No, no and no. 13000 means 13000. The Sungrow docs have +1 offset. 13001 per doc is 13000 physically.
Could anyone please give access to<EMAIL_ADDRESS>for the SH15T so we can verify what's going on (VPN, Tailscale etc...). Thanks!

@leonidnf I have compared the old and the new docs. While they have changed the naming, 13001 is still the same register (and physically 13000). It is not clean what might have changed here.

@andig
would it be possible to add a third sungrow inverter categorie which is using the configuration from @leonidrm?
So others could test/use it meanwhile the clarification with Sungrow is on going?
I also raised this issue a couple of weeks ago.
What I saw, was that users of the new SHxxT Series all were struggling with that Battery issue.
Also within the mkaiser integration. But there it was solved with the change of the calculation, simlar to that what @leonidrm now suggested here.
For me it would be a big comfort step in using evcc.
Currently, I have to care manually that the car is not discharging the battery.

Thanks for your explanation.

Could anyone please give access to<EMAIL_ADDRESS>for the SH15T so we can verify what's going on (VPN, Tailscale etc...). Thanks!

I will try to give you access to the SH15T via Tailscale; but first I have to change and secure my network setup 😇
The SHxxT series do not have a separate ethernet port; modbus must be handled via WiNet-S Dongle.
Thanks Christian

I got an answer from sungrow (translated from german):

Dear customer,
We are sending you the latest document containing the communication protocols in the attachment. The document applies to both the SHxxT and SHxxRT series inverters. You will also find the information from the training on the SHxxT inverter series attached.
Please feel free to attend our next training for installers!
Training for installers: https://germany-sungrow.clickmeeting.com/

TI_20231019_Communication Protocol of Residential Hybrid Inverter_V1.1.2_EN.pdf
Hope this helps to clarify the meanings of the modbus addresses.
@andig: I've forwarded the original email to you.

@leonidnf @Afrouper just did a test via tailscale:
[shBattery] TRACE 2024/10/29 20:38:45 modbus: send 00 01 00 00 00 06 01 04 32 dd 00 01 # 13021
[shBattery] TRACE 2024/10/29 20:38:46 modbus: recv 00 01 00 00 00 05 01 04 02 03 01    # <- 500W
[shBattery] TRACE 2024/10/29 20:38:46 modbus: send 00 02 00 00 00 06 01 04 32 c8 00 01 # 13000
[shBattery] TRACE 2024/10/29 20:38:46 modbus: recv 00 02 00 00 00 05 01 04 02 00 00    # 0!

Log clearly shows that power flow status (13000 aka 13001) is 0. This MUST NOT be.
The same happens when I put the battery into charging mode:
[shBattery] TRACE 2024/10/29 20:42:55 modbus: send 00 01 00 00 00 06 01 04 32 dd 00 01
[shBattery] TRACE 2024/10/29 20:42:55 modbus: recv 00 01 00 00 00 05 01 04 02 1f 92    # <- 8kW
[shBattery] TRACE 2024/10/29 20:42:55 modbus: send 00 02 00 00 00 06 01 04 32 c8 00 01
[shBattery] TRACE 2024/10/29 20:42:55 modbus: recv 00 02 00 00 00 05 01 04 02 00 00    # 0!

Power flow status is still 0.
I can only suggest to contact Sungrow why that is and show them the modbus traces.

@andig can you please try same thing with 13001 address?
I'm using this address for last few days and the data is accurate (same as I see in iSolar cloud)

I can only suggest to contact Sungrow why that is and show them the modbus traces.

I will send the information to sungrow support.

One more thing to test:
37. Battery Current 5631 S16 0.1A => Reg 5630 (Input)
What does it contain?
It SHOULD contain the signed value of
84. Battery current 13021 U16 0.1A => Reg 13020 (Input)

I can only suggest to contact Sungrow why that is and show them the modbus traces.

I will send the information to sungrow support.

Next week there should come an update to the WiNet-S2 Communication module to address this issue 😀

Sehr geehrter Kunde,
vielen Dank für Ihre Antwort.
Das Problem wird mit dem nächsten Update des WiNet-S2 behoben. Es sollte nächste Woche in iSC verfügbar sein. Aktualisieren Sie bitte das Kommuniaktionsmodul und lassen Sie uns bitte bis 7.11. wissen, ob das Ticket geschlossen werden kann.
Mit freundlichen Grüßen
Sungrow Service Partner

So I have to hope I will also get an update for my WiNet-S module (pending with support)
Please check your updates and report if there is a fix.

Wir haben eine ähnliche Antwort bekommen:

Bitte das Firmwareupdate des WiNet-S auf die Firmwareversion 27 durchführen welches gestern erschienen ist.

Kann das jemand ausprobieren?

Hi,
heute Nachmittag noch nicht verfügbar jetzt schon.
Gerade das Update durchgeführt und kurz die Batterie per Netz geladen; sieht gut aus:
`
shBattery
[shBattery] TRACE 2024/10/31 20:56:05 modbus: send 00 0b 00 00 00 06 01 04 32 dd 00 01
[shBattery] TRACE 2024/10/31 20:56:05 modbus: recv 00 0b 00 00 00 05 01 04 02 1f cf
[shBattery] TRACE 2024/10/31 20:56:05 modbus: send 00 0c 00 00 00 06 01 04 32 c8 00 01
[shBattery] TRACE 2024/10/31 20:56:05 modbus: recv 00 0c 00 00 00 05 01 04 02 00 22
[shBattery] TRACE 2024/10/31 20:56:05 modbus: send 00 0d 00 00 00 06 01 04 32 c8 00 01
[shBattery] TRACE 2024/10/31 20:56:05 modbus: recv 00 0d 00 00 00 05 01 04 02 00 22
[shBattery] TRACE 2024/10/31 20:56:05 modbus: send 00 0e 00 00 00 06 01 04 32 e2 00 02
[shBattery] TRACE 2024/10/31 20:56:05 modbus: recv 00 0e 00 00 00 07 01 04 04 05 d0 00 00
[shBattery] TRACE 2024/10/31 20:56:05 modbus: send 00 0f 00 00 00 06 01 04 32 de 00 01
[shBattery] TRACE 2024/10/31 20:56:05 modbus: recv 00 0f 00 00 00 05 01 04 02 00 39
Power:        -8143W
`
Auch in der UI sieht es gut aus.
Wenn ich die Antworten von Sungrow dann korrekt verstehe war der WiNet-S heute dran und der WiNet-S2 kommt nächste Woche.
Aus meiner Sicher erst mal OK. Beobachte morgen mal mit PV.
Danke an alle


Vendor using GO15VENDOREXPERIMENT

Design doc
Blog post, perhaps easier to digest

Dupe of #535?

...yup


Installing Theme Kit with Powershell throws an error

Describe the bug
When installing Theme Kit using Windows Powershell, after the command is entered, the terminal shows errors and fails to install.
To Reproduce
Steps to reproduce the behavior:

Open Windows Powershell
Enter the command to install

Expected behavior
After the insatllation command is run, the terminal shows error and fails to install.
Environment (please complete the following information):

Themekit version [e.g. v0.7.5]:
Windows 10

Error
Exception calling "DownloadingString" with "1" argument(s): "The request was aborted: Coould not create SSL/TLS secure channel."

Closing as a duplicate of https://github.com/Shopify/themekit/issues/618


why share language in english only?

The system language of my phone is frensh , but when i use the package share plus the language en ios usually  is en english.
How  to change the language popup to frensh?

That's native UI. Have you followed https://flutter.dev/docs/development/accessibility-and-localization/internationalization#localizing-for-ios-updating-the-ios-app-bundle ?

That's native UI. Have you followed https://flutter.dev/docs/development/accessibility-and-localization/internationalization#localizing-for-ios-updating-the-ios-app-bundle ?

This is the solution
Thanks

@mhadaily can I work on this task?

sure, @loud-at-heart

@loud-at-heart it seems we have a solution for this already, @tarektaamali can you confirm if the proposed solution works for you? and if so, please close this issue, if not, let @loud-at-heart know

I confirm that the fix works perfectly for me, thanks !

Thank you for confirming.


elixir mix: fix for current folder for execution

the current folder should be the project folder. There could be per-subfolder .formatter.exs files but you're not meant to run the formatter from such folders.
I ran into this exact issue:
https://elixirforum.com/t/formatter-error-in-phoenix-migrations-cant-find-ecto-sql/28764/10
This issue also happened in other editors, as can be seen in the link. The previous behavior would work fine if there was no .formatter.exs in subfolders or if these didn't rely on dependencies provided by the project-level mix.exs.
I also checked the documentation regarding the elixir formatting task:
https://hexdocs.pm/mix/1.12/Mix.Tasks.Format.html
In that documentation it's written:
. If such option is not yet available in your editor of choice, adding the required integration is usually a matter of invoking:

    cd $project && mix format $file

where $file refers to the current file and $project is the root of your project.

The root of the project would be where the mix.exs is, but again there can be .formatter.exs files in subfolders.

cc'ing the author of the PR adding this code in case he has any feedback on the change: @ethangunderson

LGTM


OpenAL issue under Windows, help!

In the v<IP_ADDRESS>-alpha release files, when using the sources directly in Windows using a fresh Eclipse, the following exception is raised:
org.lwjgl.LWJGLException: Could not locate OpenAL library.
	at org.lwjgl.openal.AL.create(AL.java:151)
	at org.lwjgl.openal.AL.create(AL.java:102)
	at org.lwjgl.openal.AL.create(AL.java:201)
	at com.badlogic.gdx.backends.openal.OpenALAudio.<init>(OpenALAudio.java:70)
	at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:80)
	at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:64)
	at hevs.gdx2d.lib.PortableApplication.createLwjglApplication(PortableApplication.java:317)
	at hevs.gdx2d.lib.PortableApplication.<init>(PortableApplication.java:72)
	at hevs.gdx2d.lib.PortableApplication.<init>(PortableApplication.java:84)
	at hevs.gdx2d.lib.PortableApplication.<init>(PortableApplication.java:94)
	at hevs.gdx2d.demos.simple.DemoCircles.<init>(DemoCircles.java:18)
	at hevs.gdx2d.demos.simple.DemoCircles.main(DemoCircles.java:27)

I saw that once in IntelliJ when I changed the project settings to UTF-8, I don't know if it is related. Do you also see that?

Unfortunately, I'm unable to reproduce the bug. I have tested demos.music.*

Any idea, anyone?

This seems to be related with accented names and the way libgdx creates temp directories for extracting natives libs. Let's hope others won't have that but I don't know how to fix this.

[LWJGL] Testing 'OpenAL64.dll'
[LWJGL] Failed to load OpenAL64.dll: Could not load OpenAL library (126)
[LWJGL] Testing 'C:\Users\uadmin\AppData\Local\Temp\libgdxuadmin\1389850411\OpenAL32.dll'
[LWJGL] Found OpenAL at 'C:\Users\uadmin\AppData\Local\Temp\libgdxuadmin\1389850411\OpenAL32.dll'

Seams to work only thit the OpenAL32.dll. I cannot reproduce this bug. Works for me on Win7 x64.

On 04/22/2015 09:38 AM, Pierre-André Mudry wrote:

This seems to be related with accented names and the way libgdx creates temp directories for extracting natives libs. Let's hope others won't have that but I don't know how to fix this.

accented names where ? in the windows user's name?

I think so... In Windows 8 you can't really choose your username as it is
linked with some Microsoft online account
On Wed, 22 Apr 2015 at 09:42 Marc Pignat<EMAIL_ADDRESS>wrote:

On 04/22/2015 09:38 AM, Pierre-André Mudry wrote:

This seems to be related with accented names and the way libgdx creates
temp directories for extracting natives libs. Let's hope others won't have
that but I don't know how to fix this.

accented names where ? in the windows user's name?
—
Reply to this email directly or view it on GitHub
https://github.com/hevs-isi/gdx2d/issues/83#issuecomment-95063675.

Can you please change your name to 7-bit-ASCII :smile: ?

Can't be reproduced easily. Hoping it won't come back since Libdx 1.5.6 update 3f6bf9efe22546161184c8b298d39a1e6854e6cb


Add SPM support

Hello. I am migrating all my pods to SPM (Swift Package Manager) and Applozic is one of the few that don't support it. Could you please add this to the project? Thanks in advance

Hello @victormihaita ,
Sorry for the late reply.
Currntly dont have an exact timeline for when we will add this SPM.
But ya we will work on this soon will keep update.


swarm config might not be working

So I tried this, which ought to bring up a swarm master?!
utopia:~ floh$ docker-machine create --driver opennebula --opennebula-template-name boot2docker --swarm-master smas
Running pre-create checks...
Creating machine...
(smas) Creating SSH key...
(smas) Starting	 VM...
(smas) Waiting for SSH...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Configuring swarm...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env smas

And I also brought up one node to join that swarm, but let's ignore that, it seems to not matter.
Let's look at the general connect instead - it seems to not be OK:
utopia:~ floh$ eval $(docker-machine env --swarm smas)
Error checking TLS connection: Connection to Swarm cannot be checked but the certs are valid. Maybe swarm is not started

The command was run a few minutes after the master was created.
I retried once more giving it 2GB ram, but no success.
docker daemon is ok:
utopia:~ floh$ eval $(docker-machine env smas)
utopia:~ floh$ docker info
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 1
Server Version: 17.06.0-ce-rc3
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 5
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.4.71-boot2docker
Operating System: Boot2Docker 17.06.0-ce-rc3 (TCL 7.2); master : 5d12baf - Tue Jun 13 21:56:36 UTC 2017
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.955GiB
Name: smas
ID: CKFJ:Z3G5:GPSD:FKB3:LUO2:WFXV:SIQV:5TJ7:LVID:V2A6:C6D2:W75F
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 16
 Goroutines: 28
 System Time: 2017-10-25T01:39:37.497170996Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=opennebula
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

So honestly I don't think this is a me problem.
If it is, please forgive me.

Or it might be an issue with the boot2docker version 17.06 vs. my local OSX one.
 Just trying to be thorough.)
utopia:~ floh$ docker-machine --help
Usage: docker-machine [OPTIONS] COMMAND [arg...]

Create and manage machines running Docker.

Version: 0.12.2, build 9371605

I am not sure if that is what's going on and don't think that's it since during install it says it configured swarm!

Tried one more thing, I passed a --swarm-discovery token://blah (though I would quite much assume that if it starts without doing that i'll autogenerate. But that's just me...)
Now,
On the client:
Swarm: inactive

On the master, at first: nope.

I'm not sure, but seems it's just a stupidity in docker-machine that it's starting the vm when not given a token but needing it. Plus some slowness in joining up.
Added another node and it seems to just take some time.
Please comment if you got anything to add, and I'll later create a PR to the README.md that should save the next person this hassle.

Hi @FlorianHeigl ,
for building a swarm cluster you can follow two approaches, one based on swarmkit and another on swarm standalone.
For swarmkit, integrated in docker, you can follow this guide.
For swarm standalone with docker-machine, you can follow the blog post. I just tested it and it works.

Hey!

what's the reason that you generally use --opennebula-image-name boot2docker --opennebula-b2d-size 10240 instead of the template that comes with it?
I noticed much of the tooling works better that way, but don't understand the story behind it.

I'll go over the readme and make sure that both these guides are pointed at where one can see it. :-)


Local embeddings with sentence transformers

Hi,
I saw that there are local LLM:s in the roadmap. It won't make much sense if you don't also use local sentecetransformers (MTEB) like instructor or e5.
I would suggest to have this looked into before local LLM:s because you could potentially use an API endpoint for local LLM:s

We would like to explore this option but will not block LLM inferencing with this, we will just have OpenAI embeddings be the only option for non-embedder services (all LLM options except OpenAI & Azure).
So phase one is any LLM selection for inferencing with no option for embedding engine selection.
Then we add more Embedding engine selection when we can find a normalized interface for it. It would be a massive pain to do sentence transformation and each embedding engine has a different API. Most are running HF models it seems
Do you know of any services that normalize the embedding API like LiteLLM does for LLM inferencing?

hey @timothycarambat litellm supports the huggingface text embedding inference api which should help here

hey @timothycarambat litellm supports the huggingface text embedding inference api which should help here

Indeed, I saw this, but it also requires us to move our backend to python or run the proxy server to have that interface available

Would just be an add to the docker-compose I believe:
version: '3.9'

name: anythingllm

networks:
  anything-llm:
    driver: bridge

services:
  anything-llm:
    container_name: anything-llm
    image: anything-llm:latest
    platform: linux/amd64
    build:
      context: ../.
      dockerfile: ./docker/Dockerfile
      args:
        ARG_UID: ${UID}
        ARG_GID: ${GID}
    volumes:
      - "../server/storage:/app/server/storage"
      - "../collector/hotdir/:/app/collector/hotdir"
      - "../collector/outputs/:/app/collector/outputs"
    user: "${UID}:${GID}"
    ports:
      - "3001:3001"
    env_file:
      - .env
    networks:
      - anything-llm
    extra_hosts:
      - "host.docker.internal:host-gateway"
litellm:
    image: ghcr.io/berriai/litellm:latest
    ports:
      - '8000:8000'
    environment:
      - PORT=8000
      - OPENAI_API_KEY=your-api-key

resolved by https://github.com/Mintplex-Labs/anything-llm/pull/361


doc: add sequoia logo at who is using

Summary
Sequoia has been an early adopter of Rspack, recognizing its potential to enhance our development workflow. Last year, I set a goal to migrate our infrastructure to Rspack in 2024. I’m pleased to share that we achieved this milestone in just six months. 🎉
Link - https://x.com/Burhan_Bharmal/status/1739863649609781412
Thanks to @ScriptedAlchemy and @hardfist for all the support. 🤘🏻
Checklist

[x] Tests updated (or not required).
[x] Documentation updated (or not required).

 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.


hard fault on _nx_tcp_socket_packet_process

I have an "almost" fully functioning port to an ARM M4 controller.
I have verified the Threadx demo programs function completely.
The netxduo is very close I believe I have the lowlevel EMAC seetup and mostly working.
I have verified I can send/receive DHCP packets as well as the DNS and SNTP set up.
But I stalls at the point where it actually starts to send/receive TCP based socket packets.
My terminal out puts looks like:
 Initializing DNS client

	DNS address: <IP_ADDRESS>

SUCCESS: DNS client initialized

Initializing SNTP client

	SNTP server 0.pool.ntp.org

	SNTP IP address: <IP_ADDRESS>

	SNTP time update: Apr 4, 2021 19:14:1.422 UTC

SUCCESS: SNTP initialized

Initializing Azure IoT Hub client

	Hub hostname: testhubti.azure-devices.net

	Device id: mydev_2

So you can see I am almost there.
The wireshark packets show good handshake for all DHCP/DNS/SNTP packets all the way up to the first TCP packet at which point it makes all the way to the nx_tcp_socket_packet_process.c line 109.
VOID  _nx_tcp_socket_packet_process(NX_TCP_SOCKET *socket_ptr, NX_PACKET *packet_ptr)
{

UINT          packet_queued =  NX_FALSE;
NX_TCP_HEADER tcp_header_copy;
VOID          (*urgent_callback)(NX_TCP_SOCKET *socket_ptr);
ULONG         header_length;
ULONG         packet_data_length;
ULONG         packet_sequence;
ULONG         rx_sequence;
ULONG         rx_window;
UINT          outside_of_window;
ULONG         mss = 0;

    /* Add debug information. */
    NX_PACKET_DEBUG(__FILE__, __LINE__, packet_ptr);

    /* Copy the TCP header, since the actual packet can be delivered to
       a waiting socket/thread during this routine and before we are done
       using the header.  */
    /*lint -e{927} -e{826} suppress cast of pointer to pointer, since it is necessary  */
    tcp_header_copy =  *((NX_TCP_HEADER *)packet_ptr -> nx_packet_prepend_ptr);

I can set a breakpoint at this last line
tcp_header_copy =  *((NX_TCP_HEADER *)packet_ptr -> nx_packet_prepend_ptr);
and it makes it here but if I do one more step it hard faults.
I am not sure how to interpret the comment or why this fails.

the last few packets look like:
88	16.902087	<IP_ADDRESS>	<IP_ADDRESS>	DNS	156	Standard query response 0xb7ff A testhubti.azure-devices.net CNAME ihsu-eastus-2.eastus.cloudapp.azure.com A <IP_ADDRESS>
89	16.903396	<IP_ADDRESS>	<IP_ADDRESS>	TCP	62	54335 → 8883 [SYN] Seq=0 Win=8192 Len=0 MSS=1460
90	16.947130	<IP_ADDRESS>	<IP_ADDRESS>	TCP	60	8883 → 54335 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1440

after this I just get a retransmission, I assume because of the failure
No.	Time	Source	Destination	Protocol	Length	Info
99	19.950324	<IP_ADDRESS>	<IP_ADDRESS>	TCP	60	[TCP Retransmission] 8883 → 54335 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1440

a bit more information. I was able to correct the hard fault issue by doing this:
    /* Copy the TCP header, since the actual packet can be delivered to
       a waiting socket/thread during this routine and before we are done
       using the header.  */
    /*lint -e{927} -e{826} suppress cast of pointer to pointer, since it is necessary  */

//    tcp_header_copy =  *((NX_TCP_HEADER *)packet_ptr -> nx_packet_prepend_ptr);
    memcpy((void *)&tcp_header_copy, (void *)packet_ptr -> nx_packet_prepend_ptr, sizeof(NX_TCP_HEADER));

not sure this is a good long term solution.
Any more insight?

Could you check the value of packet_ptr -> nx_packet_prepend_ptr? It is required to be 4 bytes aligned for IP header. From your last description, it looks like the fix is related to unaligned access.

Thank you for the help. Yes, it looks like that is the issue.
Even though this is an M4F which I understand supports unaligned access (if the SCB_CCR_UNALIGN_TRP_Msk bit in the SBC->CCR register is clear ... which it is) it is still faulting.
I can see the nx_prepend_ptr is at 0x200037d6 which is indeed in RAM space but not 4 byte aligned.
So what is the answer? do all the buffer allocations need to be fixed up so prepend_ptr end up 4 byte aligned? how do you do that?

Hi @dvescovi1 - typically, we use the hardware features of the MAC to insert two bytes of padding between the 14-byte MAC header and the payload. This aligns the payload on a 4-byte boundary.

Feel free to reopen the issue if you have further questions.


"No results found for error" - fixed

When using pacaur I was getting a "No results found for error" error on updating with pacaur -Syu on two separate systems. I was able to update each package on its own without errors.
This can be solved by updating pacaur and cower manually:
$ pacaur -S pacaur cower

This is due to the new pacman version (libalpm soname bump). Well known issue, hopefully I could fin a way to make the error more explicit in the future.


Create mhrd.txt

This vocational program is called the Academy for Mathematics, Science, and Engineering and is in Morris Hills High School. This school is located in Rockaway, New Jersey. The website is here https://www.mhrd.org/Page/863

@Rishthegreat Pull request merged. Thank you!


Measure latency in metrics

The metrics include mostly data throughput as well as cache statistics at the moment. It would be nice to know what the average latency of access within a certain time is to come to conclusion about storage tier improvements.

A naive latency on a per block basis has been implemented, this is an estimation and does not really reflect the actual latency, here we are limited in the used file struct of the standard library.


added first example and required instance

added firs example from paper

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>9:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls


ssh-keyscan options do not apply to plugin checkout

By default the buildkite agent will do an ssh-keyscan at checkout time.
However, plugins are checked out before the buildkite agent does a keyscan.
Example pipeline:
steps:
  - command: echo hello
    plugins:
      "ssh://github.com/buildkite-plugins/docker-buildkite-plugin": bash

Example output on 3.8:
upload step:
> Preparing working directory
cd /var/lib/buildkite-agent/builds/foo/bar
# Host "github.com" already in list of known hosts at "/var/lib/buildkite-agent/.ssh/known_hosts"

next step:
> Setting up plugins

Plugin "github.com/buildkite-plugins/docker-buildkite-plugin" will be checked out to "/var/lib/buildkite-agent/plugins/github-com-buildkite-plugins-docker-buildkite-plugin"
The authenticity of host 'github.com (<IP_ADDRESS>)' can't be established.
# snip
Are you sure you want to continue connecting (yes/no)? # Received cancellation signal

Note this will only happen on "fresh agents" as buildkite checkout will write to /var/lib/buildkite-agent/.ssh/known_hosts

Was this ever fixed?

Having just had a look, I can’t actually figure out how this would have been an issue at the time; plugins have had an ssh-keyscan done on them since 2017 or earlier, and in every post-beta build of the 3.x agent line. I’ll loop @lox in and see if he knows any more about what’s happened here.

Thanks @ticky; I figured out that there is an option to enable the ssh config in the plugin; which works for me.
plugins:
      - docker#v3.7.0:
          image: "ruby:2.5"
          mount-ssh-agent: true

Ah, you’re checking stuff out from inside docker? I think that’s a separate issue.  :)

I was able to reproduce this issue quite reliably. The trick is to do so on a pristine agent that has never talked to github before. The setup of the environment, including plugin cloning, is done before the checkout phase, so the keyscan has not happened yet.
You can try executing the following pipeline:
steps:
  - label: test
    command: echo 'OK'
    plugins:
      -<EMAIL_ADDRESS>{}

Start the agent:
docker run -ti --rm --name buildkite-agent-test-904 -e SSH_AUTH_SOCK="/var/ssh-agent" -v "${SSH_AUTH_SOCK}":/var/ssh-agent -e BUILDKITE_PLUGINS_ALWAYS_CLONE_FRESH=true -e BUILDKITE_AGENT_TOKEN="...REDACTED..." buildkite/agent:3.44.0

Result:

But if you, without stopping the container running the agent, do a simple: docker exec -ti buildkite-agent-test-904 ssh<EMAIL_ADDRESS>and retry the step, it works no problem:

If you stop the container and start it again, you go back to having the issue until something connects to github successfully (like a step that doesn't have any plugins referenced with SSH).
PS: this is basically what was originally reported, but the example was using the docker plugin who took all the blame :)


Example - Control BP_ThirdPersonCharacter

Currently I use dataframe to store a csv file for all actions. I wonder if there is any other tools we could use such that we could also store items such as triggered_event and ValueType all together. Maybe we could have a different generate_actions, but use the same run.py with a few different parameters for all types of pawn.


Clarify code license

As a Pebble Time backer, I love that example code for watch faces is being made available. Thanks @C-D-Lewis!
However, before I can use this as a jumping off point, I would appreciate knowing what license (or at least what style of license) it is released under. Mainly so I don't get any surprises later from e.g. the viral nature of the GPL. I'm not advocating for any particular license, just knowledge if it's permissive (BSD, MIT-like) or virally open like the GPL.
Adding a LICENSE.txt file at package root would be very helpful.

Hi @JDWarner,
Looks like we forgot to include the license when we uploaded the project to GitHub, so thanks for letting us know! All of our examples are released under the MIT license, and I have added just added a LICENSE file to the project to clarify it.


Tab characters cause grit import to panic

grit import panics if the imported file has tab delimiters. It works if tabs are converted to spaces.
I've attached the error that got thrown, as well as the two files that I used to test it.
import-with-spaces.txt (this works)
import-with-tabs.txt (this errors)
import-with-tabs.log
The files were made in nano with tabwidth of 4.

Think I've found a fix to this.
In multitree/node.go, line 313:
if origin.ID == 0 || dest.ID == 0 {
    panic("link endpoints must have IDs")
}

Changing 0 to -1 fixes the problem and multitree_test.go still passes. Initialising NewNode with an ID with 1 on line 24 seems to fix things too.
Not sure if this will cause problems elsewhere?

You're on the right track, but I suspect there's a lot more wrong going on there -- the truth is I forgot about the command during the switch from DAGs to multitrees, if I'm not mistaken. The import code doesn't have any tests either!
I'll fix it for the next release and add the tests, probably tomorrow -- I had it working before so it shouldn't take long.
BTW, it doesn't work for spaces either, it's just including them in task names :smile:. I will definitely have to add support for spaces too.

Yeah I realised the spaces thing today when I was looking at it today, I just managed to confuse myself!
I have imports working, I think as intended minus the spaces thing. I can submit a pull request if you want, although I haven't written tests.

4f226b00128d285bd66c9edf03e8b719eb27f489 probably would cause other problems, and in 3c266a88878495c4cd8e510b52328941eb97bb6d the function shouldn't accept zero, since it's used for user-provided selectors elsewhere -- I shouldn't have used the function there to begin with, and it's fixed now. 6e518bdbf9e261827a0addc7ce1360b157f62eb9 was spot on, thanks for pointing that out!
I ended up reworking the whole thing, it was too confusing. The were also some other issues, like not updating ancestors after insertion.
Props for trying to make sense of that mess! :smile:

Yeah I kind of expected those would break something else, glad to help though.
Really cool project btw :smile:


ci: nix flake show comment in prs

What'd be even cooler, IMO, would be to show the differences.
What works quite nicely on my machine:
$ export REF=refs/heads/main
$ delta \
  <(nix flake show ".?ref=$REF&rev=$(git rev-parse $REF)" | nix run nixpkgs#ansifilter) \
  <(nix flake show | nix run nixpkgs#ansifilter)

So, for GitHub Actions we'd probably need:
diff -u \
  <(nix flake show ".?ref=$GITHUB_REF&rev=$(git rev-parse $GITHUB_REF)" | nix run nixpkgs#ansifilter) \
  <(nix flake show | nix run nixpkgs#ansifilter)

And then use
```patch
${{ steps.flake-show.outputs.output }}
```

That would be nice. Perhaps a full-context diff?

Thank you, @lorenzleutgeb .


How can I get suggestions without ending the word?

I'm only getting suggestions when I press space or some other character like ( or { that ends the word.
I'd like to get suggestions when I pause in the middle of a word or something similar.
Is this configurable?

I tried
  sources = {
    { name = "copilot", group_index = 1, trigger_characters = { ... }  },
  }

And added in alphabet characters, but it had no effect that I can discern.

This is pretty much a dealbreaker for me. Using your other copilot plugin alone gets me results faster, and more often, event when I just enter into the next new line with no text. HAVING to type something, and a whole word at that makes this much less useful. The problem with that though, is that I can't accept the answers, since  is used by nvim-cmp.
Is there a way to manually trigger copilot completions when I want them? Or a way to configure it to trigger on newlines, and on normal text characters (I expect the debounce from copilot.lua will still work)?
I've spent hours on this.

I'm a bit confused here. If you want to have completions manually triggered, thats a cmp feature. You can set a hotkey to fetch completions from a particular source in your cmp config
    ["<C-s>"] = cmp.mapping.complete({
        config = {
          sources = {
            { name = 'copilot' },
          }
        }
      }),

Also, it seems like your issue is with copilot-cmp, so why swap to copilot.vim when copilot.lua provides all of its features? Is there something here I am missing?

This plugin by default severely restricts trigger.
Just edit keyword_pattern:
{ name = "copilot", keyword_pattern = "." },

This plugin by default severely restricts trigger.
Just edit keyword_pattern:

{ name = "copilot", keyword_pattern = "." },

That may be a bug in my last commit. I actually thought it was triggering more often when I wrote it but it seems it is not. I'll fix this now.


systemd: Don't order systemd-user-sessions.service after network.target

Fix delayed startups waiting for DHCP, see #60900
The startup time issue seems much more annoying to me than the original SSH session issue, so I think we should merge this now. If others disagree, I guess we wait until we have a proper fix for the latter.
Motivation for this change
Improve boot times for local NixOS users.
Things done
I tested by overriding the package in configuration.nix:
systemd.package = pkgs.callPackage /home/craig/nixpkgs/pkgs/os-specific/linux/systemd/default.nix {};

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Instead of patching the upstream unit which causes an unecessarry mass rebuild, we can override it within the systemd nixos module
https://github.com/NixOS/nixpkgs/blob/15d6b7740200bd22bbb0659ab41792b6c93017d3/nixos/modules/system/boot/systemd.nix#L921

Madness, all madness! :laughing: .
This all seems like we've made things a bit of a mess? I apologize for any misunderstanding, but here's what it looks like:

wtf @ making everyone wait for network because other folks can't be bothered to use network-online.target if they need connectivity before running.  (is this an accurate summary of the situation?)
Not having network disappear out from user services.. seems like the right/appropriate behavior. Please don't casually change that? Is the alternative ordering "remove network interfaces, THEN try to stop user services"?? Because if that's correct that seems rather hostile and likely problematic.  At that point we might as well just make step one "cut power to the entire rack" and only afterwards signal user services... ;).
I don't understand why "waiting for dhcpcd to fork" is somehow a significant delay (but apparently it is, and I'm sure it has reasons that make sense <3), but reading our thread on the issue it appears what happened was someone said "my cloud-init use case would be improved as a result of this change" so the change was made but as a result (unexpectedly) a number of users report giant delays in day-to-day use of their actual machine.
This does not seem like we made the right trade-off here, right? Ideally all use cases can be accommodated but I must say.... "why does your laptop take 30 seconds to boot, with a black screen with no indication of progress" => "because someone wanted to use cloud-init and apparently that means we have to intentionally degrade things for all" --- not at all hating on cloud-init but it seems poorly motivated.  More importantly, IMO, there seems no technical justification for imposing this "cost" across all users-- other solutions or even just adding an option?

I suppose I'm inclined to say we just revert the other change and.... add a dependency on network-online,target from cloud-init? (err surely it's not that simple? sorry)

Thanks for working on this, hopefully we can get this sorted soon.  See also #60954 , I'm working on related issues as well.

Instead of patching the upstream unit which causes an unecessarry mass rebuild, we can override it within the systemd nixos module

Unfortunately, this doesn't appear to be possible for dependency configuration. All nix-specified unit options are placed in a drop-in file:
$ systemctl status systemd-user-sessions.service
● systemd-user-sessions.service - Permit User Sessions
   Loaded: loaded (/nix/store/nih5bga6fwphwm1la0wy2pxnv2wng675-systemd-239.20190219/example/systemd/system/systemd-user-sessions.service; enabled; vendor preset: enabled)
  Drop-In: /nix/store/mfmr9a17jg7j9bkrj8xwg4zlf29v2mgy-system-units/systemd-user-sessions.service.d
           └─overrides.conf

But drop-ins are unable to remove dependencies, only add them, as explained in the small print at the end of systemd.unit(5):

Note that for drop-in files, if one wants to remove entries from a setting that is parsed as a list (and is not a dependency), such as AssertPathExists= (or e.g.  ExecStart= in service units), one needs to first clear the list before re-adding all entries except the one that is to be removed. Dependencies (After=, etc.) cannot be reset to an empty list, so dependencies can only be added in drop-ins. If you want to remove dependencies, you have to override the entire unit.

I suppose we ought to find a better way to deal with this.
Your comment did make me think to try overriding the derivation:
    systemd.package =
      pkgs.systemd.overrideAttrs (oldAttrs:
       { patches = [ /etc/nixos/user-sessions-not-after-network.patch ]; });

but while it works in configuration.nix, it fails silently in boot/systemd.nix, seemingly ignoring it completely:
$ sudo nixos-rebuild switch -I ~/nixpkgs
[sudo] password for craig:
building Nix...
building the system configuration...
activating the configuration...
setting up /etc...
reloading user units for craig...
setting up tmpfiles
$ systemctl list-dependencies systemd-user-sessions.service --after | grep network.target
● ├─network.target

Is that expected? It seems strange that there's no error at all.

Madness, all madness!

I gazed long into the bug, and the bug also gazed into me :)

I apologize for any misunderstanding

That's quite alright, I'm just glad anyone is interested!

wtf @ making everyone wait for network because other folks can't be bothered to use network-online.target if they need connectivity before running.  (is this an accurate summary of the situation?)

Re-reading #44524, I think this is pretty much it, actually.
I don't think the concern about IPv4/IPv6 is warranted, since with the current behaviour, services may be relying on network.target, which will already activate as soon as one of the two is ready. Nothing breaks here if we change to network-online.target in both cases.

Not having network disappear out from user services.. seems like the right/appropriate behavior. Please don't casually change that? Is the alternative ordering "remove network interfaces, THEN try to stop user services"?? Because if that's correct that seems rather hostile and likely problematic.  At that point we might as well just make step one "cut power to the entire rack" and only afterwards signal user services... ;).

Haha! If I understand correctly (certainly this is how it's documented - see the manpage), systemd-user-sessions.service does not actually have anything much to do with sessions in the systemd sense, or with user services at all, but it merely needs to run to allow user logins.
This is why I referred to the upstream change as a hack - it only happens to work for SSH because disabling logins with PAM will forcibly close the inbound SSH sessions. Instead, systemd should have a principled way to terminate those sessions either 1) when sshd.service is stopped or 2) before network-online.target is unreached.
It's true, I think, that killing user logins will kill any services running under users who are not set to linger. However, systemd-user-sessions.service is ordered before the user's scope, and I am pretty sure that systemd must terminate the user's processes and services before closing their scope!
$ systemctl list-dependencies systemd-user-sessions.service --before
systemd-user-sessions.service
●<EMAIL_ADDRESS>● ├─session-1.scope
● ├─systemd-ask-password-wall.service
●<EMAIL_ADDRESS>

I don't understand why "waiting for dhcpcd to fork" is somehow a significant delay

It waits to acquire a lease, so that depends how fast your DHCP server is ;) it may take several seconds even if nothing is wrong. By default, dhcpcd is more cautious than networkd. More importantly, if you have no network connection, then you must wait for dhcpcd to timeout!

add a dependency on network-online,target from cloud-init?

I think this particular fix is already in place.

Thanks for working on this, hopefully we can get this sorted soon. See also #60954 , I'm working on related issues as well.

Cheers mate, keep fighting the good fight!

I'm really not in favour of increasing our amount of patches on top of systemd.

Hah, yes, I see what you mean. Though unless I'm missing something, the existing ones are Debian's patches, not ours. Running patchPhase against systemd/master, it appears that most of them are outdated, so should this be a concern going forward?
(Actually, I don't understand this at all. If we are maintaining our own branches of systemd, why are we pulling patches from other people??)

Reading up on #60900 and #44524 (comment):
It seems adding dhcpcd.service to network.target is wrong, it should be requiredBy=network-online.target

Agreed, for sure! However...
I would like to clarify that this change is not merely a workaround for a bad interaction with dhcpcd. The upstream config is a bug, regardless of whether it takes 30 seconds or 30 milliseconds to reach network.target, because user logins shouldn't have to wait for network adapters. It's semantically wrong, and I intend to file an issue upstream also :)

I'm really not in favour of increasing our amount of patches on top of systemd.

Hah, yes, I see what you mean. Though unless I'm missing something, the existing ones are Debian's patches, not ours. Running patchPhase against systemd/master, it appears that most of them are outdated, so should this be a concern going forward?
(Actually, I don't understand this at all. If we are maintaining our own branches of systemd, why are we pulling patches from other people??)

These branches add some NixOS-specific things on top of systemd, but while doing so, also accidentially break systemd-tmpfiles - see https://github.com/NixOS/nixpkgs/pull/56265#issuecomment-487095394 for that discussion

Reading up on #60900 and #44524 (comment):
It seems adding dhcpcd.service to network.target is wrong, it should be requiredBy=network-online.target

Agreed, for sure! However...
I would like to clarify that this change is not merely a workaround for a bad interaction with dhcpcd. The upstream config is a bug, regardless of whether it takes 30 seconds or 30 milliseconds to reach network.target, because user logins shouldn't have to wait for network adapters. It's semantically wrong, and I intend to file an issue upstream also :)

Yes, please engage upstream in the discussion, that's where these things should be solved :-)

@gloaming can this be rebased and rechecked across current master (contains systemd 242)? Did you check back with upstream on how this should be done?

Rebased and tested locally using systemd.package again. I got hit by https://github.com/NixOS/nixpkgs/issues/31540, but that appears to be unrelated to this change. Otherwise everything seems OK!
@flokli I haven't contacted upstream yet, I'll try to get that done in the next couple of days.
I realised why the overrideDerivation in boot/systemd.nix didn't work - I was doing -I ~/nixpkgs instead of -I nixpkgs=~/nixpkgs. Oops! I'll look into it again. Would it make sense to add some foolproofing around that, i.e. warn if the added path is a nixpkgs tree?

I filed a PR at https://github.com/NixOS/systemd/pull/28, which seems more logical than adding a patch in Nixpkgs.

@gloaming we should contact upstream (github.com/systemd/systemd) first, before adding custom patches on our fork of systemd.

Upstream issue filed at https://github.com/systemd/systemd/issues/12853

@gloaming reading into nixos/modules/services/networking/dhcpcd.nix, I think the right way to fix this would be changing dhcpcd.service to be before = ["network-online.target"], not ["network.target"].
We fixed the cloud-init problem descibed at 48f7778d996fae8ab5e7177ac39ce9e86ed37b9b in 57840dbffb38d6717130bf446935beff5bb12dfe by setting wants = ["network-online.target"], so network.target (and systemd-user-sessions too) should be reached quite quickly.
Can you check if changing dhcpcd.service works for you?
cc @vincentbernat

@flokli Yes, we should do that for sure. I still think upstream should fix the other ordering, but once we fix dhcpcd.service it won't really matter.
I've retested that ordering against this morning's release-19.03 and it looks good. Shall a file a new PR and close this one?

I'm personally fine with how upstream did their ordering, and how they define network.target:

network.target has very little meaning during start-up. It only indicates that the network management stack is up after it has been reached. Whether any network interfaces are already configured when it is reached is undefined. Its primary purpose is for ordering things properly at shutdown: since the shutdown ordering of units in systemd is the reverse of the startup ordering, any unit that is order After=network.target can be sure that it is stopped before the network is shut down if the system is powered off. This allows services to cleanly terminate connections before going down, instead of abruptly losing connectivity for ongoing connections, leaving them in an undefined state.

We just have dhcpcd being part of the wrong target, so yes, please file a PR fixing this against master :-)

Closed in favour of #64621.


Add functions _.containsAll and _.containsAny

contains does not currently work with arrays (https://github.com/jashkenas/underscore/issues/1615) and the current workarounds for this aren't very readable.
This PR adds two methods for testing whether a collection includes all or any values from another collection.
_.containsAll([1, 2, 3], [1, 3]); //=> true
_.containsAll([1, 2, 3], [1, 4]); //=> false

_.containsAny([1, 2, 3], [1, 4]); //=> true
_.containsAny([1, 2, 3], [4, 5]); //=> false

What's wrong with just using _.every and _.any?
_.every(subArray, function(i) { return _.contains(array, i); });
_.any(subArray, function(i) { return _.contains(array, i); });

@jridgewell Thanks for the update to _.contains. I profiled using _.intersection vs _.every + _.partial and found the latter to be much more performant so I went ahead and changed my implementation to use that approach.
I'll leave this PR open in case anyone feels it would be valuable to have these methods as shortcuts for readability and also to promote a more performant solution for array comparison.

Though this can definitely be useful, I believe this belongs in mixin land for now. Thanks!

Plus one on this. I think it will be very useful and easy to implement based on existing functions.


Using Loopback standard filters for pagination

Hello,
I am trying to connect my ng-admin instance to a RESTful API powered by loopback.io framwork.
The basic operations work out of the box (listing, edit, show, delete) which is really great.
When it comes to pagination of the listing ng-admin seems to use the query parameters ?_perPage=x and &_page=y by default. Unfortunately loopback supports this by filters which are used like ?filter[limit]=x and &filter[offset]=y
A GET URL would look like http://localhost:3000/api/questions/?filter[limit]=5&filter[offset]=2
I found this code snippet which should be used to customize attribute names in ng-admin avoiding a customization of the api itself:
app.config(function(RestangularProvider) {
RestangularProvider.addFullRequestInterceptor(function(element, operation, what, url, headers, params, httpConfig) {
if (operation == 'getList' && what == 'entityName') {
params.offset = (params._page - 1) * params._perPage;
params.end = params._perPage;
delete params._page;
delete params._perPage;
}
return { params: params };
});
});
I think it would be possible to build an URL like http://localhost:3000/api/questions/?limit=5&offset=2 but nothing like http://localhost:3000/api/questions/?filter[limit]=5&filter[offset]=2 with this solution.
Is there already a clean approach to adopt ng-admin to the loopback pagination pattern?
Maybe there is a very simple solution which I don't see at the moment as I am just diving into the Javascript world.
Thank you in advance
Philipp

I faced the same problem when trying to connect ng-admin with a SailsJS powered API which uses limit and skip keywords for pagination. Bounding the param names to a concrete backend framework sounds like a bad idea... I'd say a solution could be to make this configuration available from NgAdminConfigurationProvider and provide some default fallback param names?

@sgimeno, you can already customize how your URL should look like, using request interceptors. Here is an example to respond to @philippdhh question (sorry for the delay btw):
RestangularProvider.addFullRequestInterceptor(function(element, operation, what, url, headers, params) {
    if (operation == "getList") {
        // add new parameters
        params['filter[limit]'] = params._perPage;
        params['filter[offset]'] = params._page;

        // remove old obsolete ones
        delete params._perPage;
        delete params._page;
    }

    return { params: params };
});


CAMEL-12654: RabbitMQ Headers - Headers with null value are skipped

@oscerd what do you think about backport this component to 2.21 and 2.22. I've added a new option but it doesn't change the default behaviour?

Should be fine if the behavior doesn't change it would be good.

@oscerd , thanks. Will do it.


PathFollower.startFollow broken between 3.21.0 and 3.22.0 ?

It seems that startFollow does not take the duration when using phaser 3.22.0.
In the joint example the triangle goes as fast as possible from the start of the line to the end on space hit. The funny part is that the evaluated elapsed time using onStart/onComplete callbacks is pretty good (5.0...s in the joint example).
I browse a little in github between the versions of a couple of related files but I am not expert enough  to have found anything.
On Version 79.0.3945.130 (Official Build) (64-bit)/Ubuntu 18.04.3 LTS
Same issue with FireFox 72.0.2 (64-bit)
But using 3.21.0 (or older) things are ok.
Btw, inline "official samples" seem  to have the same trouble:
ex: https://phaser.io/examples/v3/view/paths/followers/change-path#
https://phaser.io/examples/v3/view/paths/followers/basic-follower
Nothing is moving (or  everything moves once very fast) until you ask for 3.21.0 with the menu.
To be used within a poor html page.
window.addEventListener("DOMContentLoaded", (event) => {
'use strict';
var config = {
type: Phaser.AUTO,
width: 800,
height: 600,
backgroundColor: '#2d2d2d',
physics: {
default: 'arcade',
arcade: {
gravity: {x: 0,  y: 0 },
debug: true
}
},
scene: {
init: init,
preload: preload,
create: create,
update: update
}
};
new Phaser.Game(config);
var follower;
var path;
var graphics;

function init(){

}

function preload () {

//DEBUG
window.scene=this;

//this.load.image('player', '../assets/firstaid.png');
}

function create (){
const line=new Phaser.Curves.Line(new Phaser.Math.Vector2(0,0), new Phaser.Math.Vector2(300, 300));
let g=this.add.graphics({x:0, y:0});
g.lineStyle(5, 0xFF0000, 1.0);
line.draw(g);

path = this.add.path(0, 0);
path.add(line);

g=this.add.graphics();
g.setVisible(false);
g.fillStyle(0x00ff00, 1);
g.beginPath();
g.moveTo(0,0);
g.lineTo(30, 10);
g.lineTo(0, 20);
g.lineTo(0, 0);
g.fillPath();
g.generateTexture('player',60,40);
follower = this.add.follower(path, 0, 0, 'player');

window.follower=follower;
this.cursors=this.input.keyboard.createCursorKeys();
}

function update(){
var deltaT;
if (this.cursors.space.isDown && !follower.isFollowing()){
    follower.startFollow({
	duration: 5*1000,
	useFrames: false,
	from:0,
	to:1,
	repeat: 0,
	positionOnPath:true,
	rotateToPath: true,
	onComplete:()=>{ deltaT-=Date.now(); console.log("FINITO %s s",  -deltaT/1000); },
	onStart:()=>{ deltaT=Date.now(); console.log("STARTED"); },
    });

    console.log("startFollow");
   // follower.startFollow(4000);
}
}// update

});//  DOMContentLoaded

Thank you for spending time reporting this issue. However, we've already fixed this in the master branch of Phaser and it will be part of the next official release. You can track what's already been fixed by searching closed issues, or by looking at the Change Log.


Bearings View not working

First I'd like to say that I love the plugin, it's the perfect mix of Metafolders and Breadcrumbs for me, and has replaced both on all my Vaults; however, I don't seem to be able to get the bearings view code blocks to work. I might be using it wrong, in which case more documentation is needed, or it might be broken.
From what I can tell from the readme, all that's needed is to simply add the code block as it is shown. Is more content required for a query or is meant to be empty?
Also, are there future plans to make the role labels visible within some form of display (code block view, navigation bar)? That would definitely cement this plugin as my go-to for vault organization. I'm thinking of Breadcrumbs' matrix view or page view.

Thanks for your kind comments! It's always good to hear about something being useful to others :)
(1) With respect to the codeblock, yes, in principle just having:
```bearings
````

on a page should bring up all relationships to/from that particular page.( Later on, I plan to add a YAML parser that allows specification of a differnt focal file, filters etc.)
When you say it doesn't work, what exactly is the issue? E.g., blank, or not showing the correct relationships, etc?  I know there are some glitches that need to be sorted out in code blocks (e.g. in not auto-refreshing when pages update, and they might need to be manually refreshed), but there are also numerous external issues (e.g., dataview not installed, metadata block with syntax errors so Obsidian cannot understand it, different relationship names or typos in the field names etc.).
Below are some test cases that you could add to your vault to see if it works:
This is how things should like when "running on empty", i.e. everything working but no data:
```bearings
```

This the simplest graph, a single self-linked note:
---
entry-parents:
  - "[[Untitled 1]]"
title: "**Hello** from *Note 1*"
---

```bearings
```

which can be extended:

(2) With respect to future plans -- a previous incarnation of this plugin (a javascript prototype) indeed did have some sort of indicator for the relationships. After a lot of experimentation, I settled on the most compact way would be for the arrows to be customizable relationship-specific unicode/character/strings, so, e.g., A parent-child relationship could be indicated by ⋋  connecting the node to the edge while a classifier-classified relationship could be ∋ (for e.g.). Plus some sort a tool-tip /overlay description. There are also plans to support tags like the glyphs..

Thanks for the help.
This works as intended.
```bearings
```

However, in the readme, this is the code block shown, might want to change that.
```bearings-view
```

Ah, got it. Yep, that's a documentation issue. Fixed now, thanks!

Just a quick note -- as it happens some indication of the relationships is going to make into the next release:

along with lots of richer support for node creation.

Thanks for the heads up, I'll keep an eye on it.


Fix #1221, Use quotes for local includes

Describe the contribution
Fix #1221 - Use quotes for local includes
Testing performed
Build/run unit tests (note open issue on unit tests, #1224)
Expected behavior changes
None
System(s) tested on

Hardware: cFS Dev Server
OS: Ubuntu 18.04
Versions: cFS Bundle main + this commit

Additional context
None
Third party code
None
Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC

CCB:2021-03-17: Approved
Rebased on cfe main with the unit test fix, passed.  Ready for merge.


Added MENU_HINTS client property

whereby the client renderer on the server can send hints to the remote client letting it know about which menu or popup is active, and whether or not a keyboard is required.  Also added a new API IsTouchUI that returns TRUE if the remote client is a Touch enabled device.  The Server's Version is updated to 9.0.4 to reflect new APIs and Properties.

Just a few minor changes I'm suggesting, I can merge it after those are taken care of.

Review that and see if matches what you had in mind.

Just one issue still. The other change you updated is fine now.

Ok, so, I updated format() to return null when there isn't an hint, which, to be honest, I think is what it should have done in the first place, since, format() isn't a toString() it's basically a marshalling function, and in this case there isn't any data to marshall.


reorder team tabs mostly making emojis more prominent

order according to the ticket should be:
1- Members
2- Channels
3- Emojis (swap #2 and #3 if it's a small team)
4- Settings
5- Bots
6- Subteams

@keybase/react-hackers


Downloading pictures with highest possible resolution

Is it possible to change default 480x480 resolution of downloaded pictures? Or is it rather impossible because this project use unoffical api?
Only hope to get best media quality is to either use https://developers.facebook.com/docs/messenger-platform or write selenium based scrapper?

Just came across this method https://github.com/Schmavery/facebook-chat-api/blob/master/DOCS.md#resolvePhotoUrl. This is probably the solution.

Thank you, I will test both methods shortly and create a MR. Currently just have problems downloading any media from the chats and after two tries my messenger account gets blocked and have to reset the password, so it's not easy.

Did you ever fix this issue? @jacekmusial
Trying to archive all my photos with my fiancee that we've sent to each other over the past five years 😅

@outpoints @met94 Thank you for your message outpoints, I have completely forgot about it.
Have look at https://github.com/met94/MessengerChatMediaDownloader/pull/2. But please be aware that I have to test delays , because Facebook is eager to block people.

Thanks! @jacekmusial
Will test out delays and see what works best!
Appreciate it!

Thanks! @jacekmusial
Will test out delays and see what works best!
Appreciate it!

Be careful @jacekmusial my Facebook account was just disabled...
My profile disappeared off of Messenger for everyone and now they are saying this after submitting an appeal.

I hope they actually do unban me but it's Facebook so who knows 😖

Be careful @jacekmusial my Facebook account was just disabled...
My profile disappeared off of Messenger for everyone and now they are saying this after submitting an appeal.

I hope they actually do unban me but it's Facebook so who knows 😖

@outpoints @jacekmusial I have found better solution, which worked for me. I was able to download 11k medias from one group chat. Open Chrome, log to the Messenger, open chat, open latest media and execute this script in the console https://gist.github.com/jacekmusial/5021754c01cdc26aa6183619e31aef2a
I hope you will get your account soon outpoints!

@outpoints @jacekmusial I have found better solution, which worked for me. I was able to download 11k medias from one group chat. Open Chrome, log to the Messenger, open chat, open latest media and execute this script in the console https://gist.github.com/jacekmusial/5021754c01cdc26aa6183619e31aef2a
I hope you will get your account soon outpoints!

I got my account back! This doesn't change which media is currently selected. It only spams the download for the same image, will need to figure out the class name for the next button 😅 @jacekmusial

I got my account back! This doesn't change which media is currently selected. It only spams the download for the same image, will need to figure out the class name for the next button 😅 @jacekmusial

I am happy for you @outpoints. It worked for me on several occasions, but I suspect they might change class name. Yes, I have seen a few duplicated images but never was able to resolve it. Do you have any idea what might be causing it?

I am happy for you @outpoints. It worked for me on several occasions, but I suspect they might change class name. Yes, I have seen a few duplicated images but never was able to resolve it. Do you have any idea what might be causing it?

I am happy for you @outpoints. It worked for me on several occasions, but I suspect they might change class name. Yes, I have seen a few duplicated images but never was able to resolve it. Do you have any idea what might be causing it?

Yes! It was simply removing  downloadButton[0].click(); on line 13 that fixed it!
I was able to download 16k images via that script :)

I am happy for you @outpoints. It worked for me on several occasions, but I suspect they might change class name. Yes, I have seen a few duplicated images but never was able to resolve it. Do you have any idea what might be causing it?

Yes! It was simply removing  downloadButton[0].click(); on line 13 that fixed it!
I was able to download 16k images via that script :)


Problem building version 55 in Docker container

(Continuation of https://github.com/Eloston/ungoogled-chromium/issues/129#issuecomment-264840089)
@lenormf For some reason, buildlib is using the Linux static builder instead of the Debian stretch builder. You chopped off the beginning of the log, but I can see that from this line:
2016-12-05 08:56:05,234 - DEBUG: Appending resources/linux_static/gn_flags

(Notice linux_static. It's only used in the Linux static builder)
Is your Docker container not a normal Debian stretch installation? I'm using the distro Python module to detect what distribution it's running on.
You can specify the Debian stretch builder explicitely by modifying build.py as follows:

Add import buildlib.debian below import buildlib
Replace buildlib.get_builder() with buildlib.debian.DebianStretchBuilder()

I hadn't realized I had hit a bug, I was just making a comment about the workaround I had to do.
The build finished, it produced a ungoogled-chromium_55.0.2883.75-1_linuxstatic.tar.xz archive.
As for the build container, it's a buildpack-deps official image, plus the dependencies I installed manually.
I'm building the project with the modifications you recommend -a patch would have been nice ;)- I'll let you know how that goes.

The build has ended, all the packages seem to have been successfully generated (haven't tested them yet). I've also kept the full build log if needed.

distro gives me different values for those functions even though our os-release file is the same. Which probably means that distro is using another method to detect the distribution; maybe lsb_release?
Could you try the latest master version of distro.py and report back what you get?
FYI, here's what I get with the latest version:
Python 3.5.2+ (default, Nov 22 2016, 01:00:20)
[GCC 6.2.1 20161119] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import distro
>>> distro.linux_distribution()
('Debian GNU/Linux', 'testing', 'stretch')
>>> distro.info()
{'like': '', 'version': 'testing', 'codename': 'stretch', 'id': 'debian', 'version_parts': {'major': '', 'build_number': '', 'minor': ''}}

I fixed it by installing the lsb-release package, even though there wasn't apparently any need for it. I reported the bug upstream.

The build finished, the proper dynamic builder has been selected and the packages were built. Log here.

@lenormf Good to hear. I'm marking this as invalid since it's more of a distro module issue.