hi3518ev200 bootloop with latest precompiled files

Hello,
I flashed the latest openipc-hi3518ev200-lite-8mb.bin and get a bootloop on startup.
Unfortunately, no error message is displayed.
Something looks wrong when booting kernel at the end of "Data Size" output.
U-Boot 2010.06 (Nov 14 2022 - 19:23:46)

Check Flash Memory Controller v100 ...
Card did not respond to voltage select!
No EMMC/MMC/SD device found !
In:    serial
Out:   serial
Err:   serial
RAM size: 64MB
*No SD card found!
USB:   scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot:  1  0
8192 KiB hi_fmc at 0:0 is now current device

## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.9.37-hi3518ev200
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2048515 Byteû

System startup

Uncompress.........Ok

System startup

U-Boot 2010.06 (Nov 14 2022 - 19:23:46)

Check Flash Memory Controller v100 ...
Card did not respond to voltage select!
No EMMC/MMC/SD device found !
In:    serial
Out:   serial
Err:   serial
RAM size: 64MB
*No SD card found!
USB:   scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot:  1  0
8192 KiB hi_fmc at 0:0 is now current device

## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.9.37-hi3518ev200
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2048515 Byteû

System startup

Uncompress.........Ok

System startup

U-Boot 2010.06 (Nov 14 2022 - 19:23:46)

Check Flash Memory Controller v100 ...
Card did not respond to voltage select!
No EMMC/MMC/SD device found !
In:    serial
Out:   serial
Err:   serial
RAM size: 64MB
*No SD card found!
USB:

I dumped the output with screen -L -Logfile boot.log.
boot.log
I've tried flashing multiple times (u-boot, kernel, rootfs), but with no luck.
What is wrong?
Is more information needed?
How can I help to find the issue?

You have a problem with the installed kernel
Please show the response of the printenv command

I have flashed the complete firmware as well as individual parts several times, but without improvement.
The board resets itself when the kernel starts.
I don't see any kernel messages or other error messages.
When I set verify=y I see a little more output, but still reset.
Maybe a similar problem as with issue #646.
Maybe @dimerr can help.

Erasing at 0x70000 --   6% complete.
Erasing at 0x80000 --   9% complete.
Erasing at 0x90000 --  12% complete.
Erasing at 0xa0000 --  15% complete.
Erasing at 0xb0000 --  18% complete.
Erasing at 0xc0000 --  21% complete.
Erasing at 0xd0000 --  25% complete.
Erasing at 0xe0000 --  28% complete.
Erasing at 0xf0000 --  31% complete.
Erasing at 0x100000 --  34% complete.
Erasing at 0x110000 --  37% complete.
Erasing at 0x120000 --  40% complete.
Erasing at 0x130000 --  43% complete.
Erasing at 0x140000 --  46% complete.
Erasing at 0x150000 --  50% complete.
Erasing at 0x160000 --  53% complete.
Erasing at 0x170000 --  56% complete.
Erasing at 0x180000 --  59% complete.
Erasing at 0x190000 --  62% complete.
Erasing at 0x1a0000 --  65% complete.
Erasing at 0x1b0000 --  68% complete.
Erasing at 0x1c0000 --  71% complete.
Erasing at 0x1d0000 --  75% complete.
Erasing at 0x1e0000 --  78% complete.
Erasing at 0x1f0000 --  81% complete.
Erasing at 0x200000 --  84% complete.
Erasing at 0x210000 --  87% complete.
Erasing at 0x220000 --  90% complete.
Erasing at 0x230000 --  93% complete.
Erasing at 0x240000 --  96% complete.
Erasing at 0x250000 -- 100% complete.
Writing at 0x60000 --   3% complete.
Writing at 0x70000 --   6% complete.
Writing at 0x80000 --   9% complete.
Writing at 0x90000 --  12% complete.
Writing at 0xa0000 --  16% complete.
Writing at 0xb0000 --  19% complete.
Writing at 0xc0000 --  22% complete.
Writing at 0xd0000 --  25% complete.
Writing at 0xe0000 --  28% complete.
Writing at 0xf0000 --  32% complete.
Writing at 0x100000 --  35% complete.
Writing at 0x110000 --  38% complete.
Writing at 0x120000 --  41% complete.
Writing at 0x130000 --  44% complete.
Writing at 0x140000 --  48% complete.
Writing at 0x150000 --  51% complete.
Writing at 0x160000 --  54% complete.
Writing at 0x170000 --  57% complete.
Writing at 0x180000 --  60% complete.
Writing at 0x190000 --  64% complete.
Writing at 0x1a0000 --  67% complete.
Writing at 0x1b0000 --  70% complete.
Writing at 0x1c0000 --  73% complete.
Writing at 0x1d0000 --  76% complete.
Writing at 0x1e0000 --  80% complete.
Writing at 0x1f0000 --  83% complete.
Writing at 0x200000 --  86% complete.
Writing at 0x210000 --  89% complete.
Writing at 0x220000 --  92% complete.
Writing at 0x230000 --  96% complete.
Writing at 0x240000 --  99% complete.
Writing at 0x243edb -- 100% complete.

Erasing at 0x270000 --   2% complete.
Erasing at 0x280000 --   3% complete.
Erasing at 0x290000 --   5% complete.
Erasing at 0x2a0000 --   6% complete.
Erasing at 0x2b0000 --   7% complete.
Erasing at 0x2c0000 --   8% complete.
Erasing at 0x2d0000 --  10% complete.
Erasing at 0x2e0000 --  11% complete.
Erasing at 0x2f0000 --  12% complete.
Erasing at 0x300000 --  13% complete.
Erasing at 0x310000 --  15% complete.
Erasing at 0x320000 --  16% complete.
Erasing at 0x330000 --  17% complete.
Erasing at 0x340000 --  18% complete.
Erasing at 0x350000 --  20% complete.
Erasing at 0x360000 --  21% complete.
Erasing at 0x370000 --  22% complete.
Erasing at 0x380000 --  23% complete.
Erasing at 0x390000 --  25% complete.
Erasing at 0x3a0000 --  26% complete.
Erasing at 0x3b0000 --  27% complete.
Erasing at 0x3c0000 --  28% complete.
Erasing at 0x3d0000 --  30% complete.
Erasing at 0x3e0000 --  31% complete.
Erasing at 0x3f0000 --  32% complete.
Erasing at 0x400000 --  33% complete.
Erasing at 0x410000 --  35% complete.
Erasing at 0x420000 --  36% complete.
Erasing at 0x430000 --  37% complete.
Erasing at 0x440000 --  38% complete.
Erasing at 0x450000 --  40% complete.
Erasing at 0x460000 --  41% complete.
Erasing at 0x470000 --  42% complete.
Erasing at 0x480000 --  43% complete.
Erasing at 0x490000 --  45% complete.
Erasing at 0x4a0000 --  46% complete.
Erasing at 0x4b0000 --  47% complete.
Erasing at 0x4c0000 --  48% complete.
Erasing at 0x4d0000 --  50% complete.
Erasing at 0x4e0000 --  51% complete.
Erasing at 0x4f0000 --  52% complete.
Erasing at 0x500000 --  53% complete.
Erasing at 0x510000 --  55% complete.
Erasing at 0x520000 --  56% complete.
Erasing at 0x530000 --  57% complete.
Erasing at 0x540000 --  58% complete.
Erasing at 0x550000 --  60% complete.
Erasing at 0x560000 --  61% complete.
Erasing at 0x570000 --  62% complete.
Erasing at 0x580000 --  63% complete.
Erasing at 0x590000 --  65% complete.
Erasing at 0x5a0000 --  66% complete.
Erasing at 0x5b0000 --  67% complete.
Erasing at 0x5c0000 --  68% complete.
Erasing at 0x5d0000 --  70% complete.
Erasing at 0x5e0000 --  71% complete.
Erasing at 0x5f0000 --  72% complete.
Erasing at 0x600000 --  73% complete.
Erasing at 0x610000 --  75% complete.
Erasing at 0x620000 --  76% complete.
Erasing at 0x630000 --  77% complete.
Erasing at 0x640000 --  78% complete.
Erasing at 0x650000 --  80% complete.
Erasing at 0x660000 --  81% complete.
Erasing at 0x670000 --  82% complete.
Erasing at 0x680000 --  83% complete.
Erasing at 0x690000 --  85% complete.
Erasing at 0x6a0000 --  86% complete.
Erasing at 0x6b0000 --  87% complete.
Erasing at 0x6c0000 --  88% complete.
Erasing at 0x6d0000 --  90% complete.
Erasing at 0x6e0000 --  91% complete.
Erasing at 0x6f0000 --  92% complete.
Erasing at 0x700000 --  93% complete.
Erasing at 0x710000 --  95% complete.
Erasing at 0x720000 --  96% complete.
Erasing at 0x730000 --  97% complete.
Erasing at 0x740000 --  98% complete.
Erasing at 0x750000 -- 100% complete.
Writing at 0x260000 --   1% complete.
Writing at 0x270000 --   2% complete.
Writing at 0x280000 --   3% complete.
Writing at 0x290000 --   5% complete.
Writing at 0x2a0000 --   6% complete.
Writing at 0x2b0000 --   7% complete.
Writing at 0x2c0000 --   8% complete.
Writing at 0x2d0000 --  10% complete.
Writing at 0x2e0000 --  11% complete.
Writing at 0x2f0000 --  12% complete.
Writing at 0x300000 --  13% complete.
Writing at 0x310000 --  15% complete.
Writing at 0x320000 --  16% complete.
Writing at 0x330000 --  17% complete.
Writing at 0x340000 --  18% complete.
Writing at 0x350000 --  20% complete.
Writing at 0x360000 --  21% complete.
Writing at 0x370000 --  22% complete.
Writing at 0x380000 --  24% complete.
Writing at 0x390000 --  25% complete.
Writing at 0x3a0000 --  26% complete.
Writing at 0x3b0000 --  27% complete.
Writing at 0x3c0000 --  29% complete.
Writing at 0x3d0000 --  30% complete.
Writing at 0x3e0000 --  31% complete.
Writing at 0x3f0000 --  32% complete.
Writing at 0x400000 --  34% complete.
Writing at 0x410000 --  35% complete.
Writing at 0x420000 --  36% complete.
Writing at 0x430000 --  37% complete.
Writing at 0x440000 --  39% complete.
Writing at 0x450000 --  40% complete.
Writing at 0x460000 --  41% complete.
Writing at 0x470000 --  43% complete.
Writing at 0x480000 --  44% complete.
Writing at 0x490000 --  45% complete.
Writing at 0x4a0000 --  46% complete.
Writing at 0x4b0000 --  48% complete.
Writing at 0x4c0000 --  49% complete.
Writing at 0x4d0000 --  50% complete.
Writing at 0x4e0000 --  51% complete.
Writing at 0x4f0000 --  53% complete.
Writing at 0x500000 --  54% complete.
Writing at 0x510000 --  55% complete.
Writing at 0x520000 --  56% complete.
Writing at 0x530000 --  58% complete.
Writing at 0x540000 --  59% complete.
Writing at 0x550000 --  60% complete.
Writing at 0x560000 --  61% complete.
Writing at 0x570000 --  63% complete.
Writing at 0x580000 --  64% complete.
Writing at 0x590000 --  65% complete.
Writing at 0x5a0000 --  67% complete.
Writing at 0x5b0000 --  68% complete.
Writing at 0x5c0000 --  69% complete.
Writing at 0x5d0000 --  70% complete.
Writing at 0x5e0000 --  72% complete.
Writing at 0x5f0000 --  73% complete.
Writing at 0x600000 --  74% complete.
Writing at 0x610000 --  75% complete.
Writing at 0x620000 --  77% complete.
Writing at 0x630000 --  78% complete.
Writing at 0x640000 --  79% complete.
Writing at 0x650000 --  80% complete.
Writing at 0x660000 --  82% complete.
Writing at 0x670000 --  83% complete.
Writing at 0x680000 --  84% complete.
Writing at 0x690000 --  86% complete.
Writing at 0x6a0000 --  87% complete.
Writing at 0x6b0000 --  88% complete.
Writing at 0x6c0000 --  89% complete.
Writing at 0x6d0000 --  91% complete.
Writing at 0x6e0000 --  92% complete.
Writing at 0x6f0000 --  93% complete.
Writing at 0x700000 --  94% complete.
Writing at 0x710000 --  96% complete.
Writing at 0x720000 --  97% complete.
Writing at 0x730000 --  98% complete.
Writing at 0x740000 --  99% complete.
Writing at 0x741000 -- 100% complete.

Erasing at 0x770000 --  18% complete.
Erasing at 0x780000 --  27% complete.
Erasing at 0x790000 --  36% complete.
Erasing at 0x7a0000 --  45% complete.
Erasing at 0x7b0000 --  54% complete.
Erasing at 0x7c0000 --  63% complete.
Erasing at 0x7d0000 --  72% complete.
Erasing at 0x7e0000 --  81% complete.
Erasing at 0x7f0000 --  90% complete.
Erasing at 0x800000 -- 100% complete.

System startup
Uncompress.........Ok
System startup
U-Boot 2010.06 (Nov 14 2022 - 19:23:46)
Check Flash Memory Controller v100 ...
MMC/SD Card:
    MID:         0x3
    Read Block:  512 Bytes
    Write Block: 512 Bytes
    Chip Size:   31166976K Bytes (High Capacity)
    Name:        "SU32G"
    Chip Type:   SD
    Version:     2.0
    Speed:       50000000Hz
    Bus Width:   4bit
    Boot Addr:   0 Bytes
In:    serial
Out:   serial
Err:   serial
RAM size: 64MB
Interface:  MMC
  Device 0: Vendor: Man 035344 Snr a0fdf5ad Rev: 8.0 Prod: SU32G
            Type: Removable Hard Disk
            Capacity: 30436.5 MB = 29.7 GB (62333952 x 512)
Partition 1: Filesystem: FAT32 "NO NAME    "
reading autoupdate-uboot.img
reading autoupdate-kernel.img
reading autoupdate-rootfs.img
USB:   scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot:  1
8192 KiB hi_fmc at 0:0 is now current device
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.9.37-hi3518ev200
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2047643 Byte

System startup
Uncompress.........Ok
System startup
U-Boot 2010.06 (Nov 14 2022 - 19:23:46)
Check Flash Memory Controller v100 ...
MMC/SD Card:
    MID:         0x3
    Read Block:  512 Bytes
    Write Block: 512 Bytes
    Chip Size:   31166976K Bytes (High Capacity)
    Name:        "SU32G"
    Chip Type:   SD
    Version:     2.0
    Speed:       50000000Hz
    Bus Width:   4bit
    Boot Addr:   0 Bytes
In:    serial
Out:   serial
Err:   serial
RAM size: 64MB
Interface:  MMC
  Device 0: Vendor: Man 035344 Snr a0fdf5ad Rev: 8.0 Prod: SU32G
            Type: Removable Hard Disk
            Capacity: 30436.5 MB = 29.7 GB (62333952 x 512)
Partition 1: Filesystem: FAT32 "NO NAME    "
reading autoupdate-uboot.img
reading autoupdate-kernel.img
reading autoupdate-rootfs.img
USB:   scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot:  1
8192 KiB hi_fmc at 0:0 is now current device
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.9.37-hi3518ev200
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2047643 Byte

System startup
Uncompress.........Ok
System startup
U-Boot 2010.06 (Nov 14 2022 - 19:23:46)
Check Flash Memory Controller v100 ...

   Image Name:   Linux-4.9.37-hi3518ev200
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2047643 Bytes = 2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ...

System startup
Uncompress.........Ok
System startup
U-Boot 2010.06 (Nov 14 2022 - 19:23:46)
Check Flash Memory Controller v100 ...
MMC/SD Card:
    MID:         0x3
    Read Block:  512 Bytes
    Write Block: 512 Bytes
    Chip Size:   31166976K Bytes (High Capacity)
    Name:        "SU32G"
    Chip Type:   SD
    Version:     2.0
    Speed:       50000000Hz
    Bus Width:   4bit
    Boot Addr:   0 Bytes
In:    serial
Out:   serial
Err:   serial
RAM size: 64MB
Interface:  MMC
  Device 0: Vendor: Man 035344 Snr a0fdf5ad Rev: 8.0 Prod: SU32G
            Type: Removable Hard Disk
            Capacity: 30436.5 MB = 29.7 GB (62333952 x 512)
Partition 1: Filesystem: FAT32 "NO NAME    "
reading autoupdate-uboot.img
reading autoupdate-kernel.img
reading autoupdate-rootfs.img
USB:   scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot:  1
8192 KiB hi_fmc at 0:0 is now current device
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.9.37-hi3518ev200
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2047643 Byte

System startup
Uncompress.........Ok
System startup
U-Boot 2010.06 (Nov 14 2022 - 19:23:46)
Check Flash Memory Controller v100 ...
MMC/SD Card:
    MID:         0x3
    Read Block:  512 Bytes
    Write Block: 512 Bytes
    Chip Size:   31166976K Bytes (High Capacity)
    Name:        "SU32G"
    Chip Type:   SD
    Version:     2.0
    Speed:       50000000Hz
    Bus Width:   4bit
    Boot Addr:   0 Bytes
In:    serial
Out:   serial
Err:   serial
RAM size: 64MB
Interface:  MMC
  Device 0: Vendor: Man 035344 Snr a0fdf5ad Rev: 8.0 Prod: SU32G
            Type: Removable Hard Disk
            Capacity: 30436.5 MB = 29.7 GB (62333952 x 512)
Partition 1: Filesystem: FAT32 "NO NAME    "
reading autoupdate-uboot.img
reading autoupdate-kernel.img
reading autoupdate-rootfs.img
USB:   scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot:  1
OpenIPC #

This is my board:

I compiled the firmware myself and copied the three autoupdate-XXX.img files to the microSD card. Now the kernel starts and I also see kernel messages.
I can log in as root, but after a reboot the kernel no longer starts.
The same problem as before. The board resets itself when the kernel starts.
What could be the problem???
Operation at 0x10000 --  48% complete.
Operation at 0x20000 --  96% complete.
Operation at 0x2111c -- 100% complete.
reading autoupdate-kernel.img
reading autoupdate-kernel.img
flash erase...
Operation at 0x60000 --   3% complete.
Operation at 0x70000 --   6% complete.
Operation at 0x80000 --   9% complete.
Operation at 0x90000 --  12% complete.
Operation at 0xa0000 --  15% complete.
Operation at 0xb0000 --  18% complete.
Operation at 0xc0000 --  21% complete.
Operation at 0xd0000 --  25% complete.
Operation at 0xe0000 --  28% complete.
Operation at 0xf0000 --  31% complete.
Operation at 0x100000 --  34% complete.
Operation at 0x110000 --  37% complete.
Operation at 0x120000 --  40% complete.
Operation at 0x130000 --  43% complete.
Operation at 0x140000 --  46% complete.
Operation at 0x150000 --  50% complete.
Operation at 0x160000 --  53% complete.
Operation at 0x170000 --  56% complete.
Operation at 0x180000 --  59% complete.
Operation at 0x190000 --  62% complete.
Operation at 0x1a0000 --  65% complete.
Operation at 0x1b0000 --  68% complete.
Operation at 0x1c0000 --  71% complete.
Operation at 0x1d0000 --  75% complete.
Operation at 0x1e0000 --  78% complete.
Operation at 0x1f0000 --  81% complete.
Operation at 0x200000 --  84% complete.
Operation at 0x210000 --  87% complete.
Operation at 0x220000 --  90% complete.
Operation at 0x230000 --  93% complete.
Operation at 0x240000 --  96% complete.
Operation at 0x250000 -- 100% complete.
flash write...
Operation at 0x60000 --   3% complete.
Operation at 0x70000 --   6% complete.
Operation at 0x80000 --   9% complete.
Operation at 0x90000 --  12% complete.
Operation at 0xa0000 --  15% complete.
Operation at 0xb0000 --  19% complete.
Operation at 0xc0000 --  22% complete.
Operation at 0xd0000 --  25% complete.
Operation at 0xe0000 --  28% complete.
Operation at 0xf0000 --  31% complete.
Operation at 0x100000 --  35% complete.
Operation at 0x110000 --  38% complete.
Operation at 0x120000 --  41% complete.
Operation at 0x130000 --  44% complete.
Operation at 0x140000 --  47% complete.
Operation at 0x150000 --  51% complete.
Operation at 0x160000 --  54% complete.
Operation at 0x170000 --  57% complete.
Operation at 0x180000 --  60% complete.
Operation at 0x190000 --  63% complete.
Operation at 0x1a0000 --  67% complete.
Operation at 0x1b0000 --  70% complete.
Operation at 0x1c0000 --  73% complete.
Operation at 0x1d0000 --  76% complete.
Operation at 0x1e0000 --  79% complete.
Operation at 0x1f0000 --  83% complete.
Operation at 0x200000 --  86% complete.
Operation at 0x210000 --  89% complete.
Operation at 0x220000 --  92% complete.
Operation at 0x230000 --  95% complete.
Operation at 0x240000 --  99% complete.
Operation at 0x244603 -- 100% complete.
reading autoupdate-rootfs.img
reading autoupdate-rootfs.img
flash erase...
Operation at 0x260000 --   1% complete.
Operation at 0x270000 --   2% complete.
Operation at 0x280000 --   3% complete.
Operation at 0x290000 --   5% complete.
Operation at 0x2a0000 --   6% complete.
Operation at 0x2b0000 --   7% complete.
Operation at 0x2c0000 --   8% complete.
Operation at 0x2d0000 --  10% complete.
Operation at 0x2e0000 --  11% complete.
Operation at 0x2f0000 --  12% complete.
Operation at 0x300000 --  13% complete.
Operation at 0x310000 --  15% complete.
Operation at 0x320000 --  16% complete.
Operation at 0x330000 --  17% complete.
Operation at 0x340000 --  18% complete.
Operation at 0x350000 --  20% complete.
Operation at 0x360000 --  21% complete.
Operation at 0x370000 --  22% complete.
Operation at 0x380000 --  23% complete.
Operation at 0x390000 --  25% complete.
Operation at 0x3a0000 --  26% complete.
Operation at 0x3b0000 --  27% complete.
Operation at 0x3c0000 --  28% complete.
Operation at 0x3d0000 --  30% complete.
Operation at 0x3e0000 --  31% complete.
Operation at 0x3f0000 --  32% complete.
Operation at 0x400000 --  33% complete.
Operation at 0x410000 --  35% complete.
Operation at 0x420000 --  36% complete.
Operation at 0x430000 --  37% complete.
Operation at 0x440000 --  38% complete.
Operation at 0x450000 --  40% complete.
Operation at 0x460000 --  41% complete.
Operation at 0x470000 --  42% complete.
Operation at 0x480000 --  43% complete.
Operation at 0x490000 --  45% complete.
Operation at 0x4a0000 --  46% complete.
Operation at 0x4b0000 --  47% complete.
Operation at 0x4c0000 --  48% complete.
Operation at 0x4d0000 --  50% complete.
Operation at 0x4e0000 --  51% complete.
Operation at 0x4f0000 --  52% complete.
Operation at 0x500000 --  53% complete.
Operation at 0x510000 --  55% complete.
Operation at 0x520000 --  56% complete.
Operation at 0x530000 --  57% complete.
Operation at 0x540000 --  58% complete.
Operation at 0x550000 --  60% complete.
Operation at 0x560000 --  61% complete.
Operation at 0x570000 --  62% complete.
Operation at 0x580000 --  63% complete.
Operation at 0x590000 --  65% complete.
Operation at 0x5a0000 --  66% complete.
Operation at 0x5b0000 --  67% complete.
Operation at 0x5c0000 --  68% complete.
Operation at 0x5d0000 --  70% complete.
Operation at 0x5e0000 --  71% complete.
Operation at 0x5f0000 --  72% complete.
Operation at 0x600000 --  73% complete.
Operation at 0x610000 --  75% complete.
Operation at 0x620000 --  76% complete.
Operation at 0x630000 --  77% complete.
Operation at 0x640000 --  78% complete.
Operation at 0x650000 --  80% complete.
Operation at 0x660000 --  81% complete.
Operation at 0x670000 --  82% complete.
Operation at 0x680000 --  83% complete.
Operation at 0x690000 --  85% complete.
Operation at 0x6a0000 --  86% complete.
Operation at 0x6b0000 --  87% complete.
Operation at 0x6c0000 --  88% complete.
Operation at 0x6d0000 --  90% complete.
Operation at 0x6e0000 --  91% complete.
Operation at 0x6f0000 --  92% complete.
Operation at 0x700000 --  93% complete.
Operation at 0x710000 --  95% complete.
Operation at 0x720000 --  96% complete.
Operation at 0x730000 --  97% complete.
Operation at 0x740000 --  98% complete.
Operation at 0x750000 -- 100% complete.
flash write...
Operation at 0x260000 --   1% complete.
Operation at 0x270000 --   2% complete.
Operation at 0x280000 --   3% complete.
Operation at 0x290000 --   5% complete.
Operation at 0x2a0000 --   6% complete.
Operation at 0x2b0000 --   7% complete.
Operation at 0x2c0000 --   9% complete.
Operation at 0x2d0000 --  10% complete.
Operation at 0x2e0000 --  11% complete.
Operation at 0x2f0000 --  13% complete.
Operation at 0x300000 --  14% complete.
Operation at 0x310000 --  15% complete.
Operation at 0x320000 --  17% complete.
Operation at 0x330000 --  18% complete.
Operation at 0x340000 --  19% complete.
Operation at 0x350000 --  20% complete.
Operation at 0x360000 --  22% complete.
Operation at 0x370000 --  23% complete.
Operation at 0x380000 --  24% complete.
Operation at 0x390000 --  26% complete.
Operation at 0x3a0000 --  27% complete.
Operation at 0x3b0000 --  28% complete.
Operation at 0x3c0000 --  30% complete.
Operation at 0x3d0000 --  31% complete.
Operation at 0x3e0000 --  32% complete.
Operation at 0x3f0000 --  34% complete.
Operation at 0x400000 --  35% complete.
Operation at 0x410000 --  36% complete.
Operation at 0x420000 --  38% complete.
Operation at 0x430000 --  39% complete.
Operation at 0x440000 --  40% complete.
Operation at 0x450000 --  41% complete.
Operation at 0x460000 --  43% complete.
Operation at 0x470000 --  44% complete.
Operation at 0x480000 --  45% complete.
Operation at 0x490000 --  47% complete.
Operation at 0x4a0000 --  48% complete.
Operation at 0x4b0000 --  49% complete.
Operation at 0x4c0000 --  51% complete.
Operation at 0x4d0000 --  52% complete.
Operation at 0x4e0000 --  53% complete.
Operation at 0x4f0000 --  55% complete.
Operation at 0x500000 --  56% complete.
Operation at 0x510000 --  57% complete.
Operation at 0x520000 --  59% complete.
Operation at 0x530000 --  60% complete.
Operation at 0x540000 --  61% complete.
Operation at 0x550000 --  62% complete.
Operation at 0x560000 --  64% complete.
Operation at 0x570000 --  65% complete.
Operation at 0x580000 --  66% complete.
Operation at 0x590000 --  68% complete.
Operation at 0x5a0000 --  69% complete.
Operation at 0x5b0000 --  70% complete.
Operation at 0x5c0000 --  72% complete.
Operation at 0x5d0000 --  73% complete.
Operation at 0x5e0000 --  74% complete.
Operation at 0x5f0000 --  76% complete.
Operation at 0x600000 --  77% complete.
Operation at 0x610000 --  78% complete.
Operation at 0x620000 --  80% complete.
Operation at 0x630000 --  81% complete.
Operation at 0x640000 --  82% complete.
Operation at 0x650000 --  83% complete.
Operation at 0x660000 --  85% complete.
Operation at 0x670000 --  86% complete.
Operation at 0x680000 --  87% complete.
Operation at 0x690000 --  89% complete.
Operation at 0x6a0000 --  90% complete.
Operation at 0x6b0000 --  91% complete.
Operation at 0x6c0000 --  93% complete.
Operation at 0x6d0000 --  94% complete.
Operation at 0x6e0000 --  95% complete.
Operation at 0x6f0000 --  97% complete.
Operation at 0x700000 --  98% complete.
Operation at 0x710000 --  99% complete.
Operation at 0x714000 -- 100% complete.
Erasing SPI flash, offset 0x00040000 size 64K ...done
Writing to SPI flash, offset 0x00040000 size 64K ...done
Hit any key to stop autoboot:  1
8192 KiB hi_fmc at 0:0 is now current device
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.9.37-hi3518ev200
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2049475 Bytes = 2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Loading Kernel Image ... OK
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 4.9.37 (ben@PC-R2D2) (gcc version 8.4.0 (Buildroot -g9ed8b47-dirty) ) #1 Sun Apr 2 12:50:49 CEST 2023
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt:Machine model: Hisilicon HI3518EV20X DEMO Board
Memory policy: Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line: mem=32M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 rootfstype=squashfs init=/init mtdparts=hi_sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs),-(rootfs_data)
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 26824K/32768K available (3969K kernel code, 144K rwdata, 908K rodata, 168K init, 217K bss, 5944K reserved, 0K cma-reserved)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xc2800000 - 0xff800000   ( 976 MB)
    lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc03e89d8   (3971 kB)
      .init : 0xc04ea000 - 0xc0514000   ( 168 kB)
      .data : 0xc0514000 - 0xc05381c0   ( 145 kB)
       .bss : 0xc05381c0 - 0xc056e920   ( 218 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:16 nr_irqs:16 16
VIC @fe0d0000: id 0x00641190, vendor 0x41
clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:<PHONE_NUMBER>95 ns
sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every<PHONE_NUMBER>41ns
Console: colour dummy device 80x30
Calibrating delay loop... 269.10 BogoMIPS (lpj=1345536)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x80008400 - 0x80008458
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:<PHONE_NUMBER>2750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Serial: AMBA PL011 UART driver
20080000.uart: ttyAMA0 at MMIO 0x20080000 (irq = 21, base_baud = 0) is a PL011 rev2
console [ttyAMA0] enabled
ssp-pl022 200c0000.spi: ARM PL022 driver, device ID: 0x00800022
ssp-pl022 200c0000.spi: mapped registers from 0x200c0000 to fe1c0000
ssp-pl022 200e0000.spi: ARM PL022 driver, device ID: 0x00800022
ssp-pl022 200e0000.spi: mapped registers from 0x200e0000 to fe1e0000
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
clocksource: Switched to clocksource arm,sp804
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
workingset: timestamp_bits=30 max_order=13 bucket_order=0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
jffs2: version 2.2. (NAND)
 2001-2006 Red Hat, Inc.
NET: Registered protocol family 38
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
pinctrl-single 200f0000.pinmux: 66 pins at pa fe1f0000 size 264
pinctrl-single 200f0800.pinconf: 76 pins at pa fe1f0800 size 304
pl061_gpio 20140000.gpio_chip: PL061 GPIO chip @0x20140000 registered
pl061_gpio 20150000.gpio_chip: PL061 GPIO chip @0x20150000 registered
pl061_gpio 20160000.gpio_chip: PL061 GPIO chip @0x20160000 registered
pl061_gpio 20170000.gpio_chip: PL061 GPIO chip @0x20170000 registered
pl061_gpio 20180000.gpio_chip: PL061 GPIO chip @0x20180000 registered
pl061_gpio 20190000.gpio_chip: PL061 GPIO chip @0x20190000 registered
pl061_gpio 201a0000.gpio_chip: PL061 GPIO chip @0x201a0000 registered
pl061_gpio 201b0000.gpio_chip: PL061 GPIO chip @0x201b0000 registered
pl061_gpio 201c0000.gpio_chip: PL061 GPIO chip @0x201c0000 registered
brd: module loaded
loop: module loaded
hisi-sfc hisi_spi_nor.0: SPI Nor ID Table Version 1.0
hisi-sfc hisi_spi_nor.0: all blocks is unlocked.
hisi-sfc hisi_spi_nor.0: mx25l6436f (Chipsize 8 Mbytes, Blocksize 64KiB)
5 cmdlinepart partitions found on MTD device hi_sfc
5 cmdlinepart partitions found on MTD device hi_sfc
Creating 5 MTD partitions on "hi_sfc":
0x000000000000-0x000000040000 : "boot"
0x000000040000-0x000000050000 : "env"
0x000000050000-0x000000250000 : "kernel"
0x000000250000-0x000000750000 : "rootfs"
0x000000750000-0x000000800000 : "rootfs_data"
SPI Nand ID Table Version 2.6
Cannot found a valid SPI Nand Device
hisi_spi_nand_probe(171): Error: driver probe, result: -19
 (null): /soc/mdio@10091100/ethernet-phy@1 has invalid PHY address
hisi_femac_get_phy_addr: get PHY address failed!
libphy: hisi_femac_mii_bus: probed
mdio_bus 10091100.mdio: /soc/mdio@10091100/ethernet-phy@1 has invalid PHY address
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 0
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 1
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 2
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 3
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 4
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 5
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 6
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 7
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 8
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 9
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 10
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 11
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 12
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 13
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 14
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 15
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 16
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 17
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 18
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 19
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 20
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 21
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 22
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 23
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 24
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 25
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 26
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 27
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 28
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 29
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 30
mdio_bus 10091100.mdio: scan phy ethernet-phy at address 31
libphy: Fixed MDIO Bus: probed
Generic PHY 10091100.mdio:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=10091100.mdio:00, irq=-1)
phy_id=0x0000ffff, phy_mode=rmii
hisi-femac 10090000.ethernet: using random MAC address 32:8d:17:23:1a:1e
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-platform: EHCI generic platform driver
ehci-platform 100b0000.ehci: EHCI Host Controller
ehci-platform 100b0000.ehci: new USB bus registered, assigned bus number 1
ehci-platform 100b0000.ehci: irq 31, io mem 0x100b0000
ehci-platform 100b0000.ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-platform: OHCI generic platform driver
ohci-platform 100a0000.ohci: Generic Platform OHCI controller
ohci-platform 100a0000.ohci: new USB bus registered, assigned bus number 2
ohci-platform 100a0000.ohci: irq 32, io mem 0x100a0000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
i2c /dev entries driver
usbcore: registered new interface driver i2c-tiny-usb
hisi-i2c-hisilicon 200d0000.i2c: Hisilicon [i2c-0] probed!
hisi-i2c-hisilicon 20240000.i2c: Hisilicon [i2c-1] probed!
hisi-i2c-hisilicon 20250000.i2c: Hisilicon [i2c-2] probed!
himci: mmc host probe
himci: mmc host probe
mmc0: new high speed SDHC card at address e624
mmcblk0: mmc0:e624 SU32G 29.7 GiB
 mmcblk0:
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
hisi-dmac 10060000.hidma-controller: hidmac probe!
NET: Registered protocol family 10
NET: Registered protocol family 17
VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
devtmpfs: mounted
Freeing unused kernel memory: 168K (c04ea000 - c0514000)
This architecture does not have kernel memory protection.
random: fast init done
Sun Apr  2 10:53:31 GMT 2023
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Loading modules:modprobe: module exfat not found in modules.dep
Initializing random number generator: FAIL
Starting rngd: OK
Starting mdev...
Starting network: udhcpc: started, v1.33.2
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, forking to background
Starting ntpd: OK
Starting dropbear sshd: OK
Production mode. Enabling Basic Auth
Starting httpd: OK
Starting mini-snmpd: DISABLED, OK
Starting telnetd: DISABLED, OK
Starting crond: OK
Starting motiondetection.sh: OK
Starting telegram-bot.sh: OK
hisilicon: Check MAC for Xiongmai devices
hisilicon: The eth0 interface has a lousy MAC, let's try to change it..
Nothing found.
hisilicon: It is not possible to install a new MAC on the eth0 interface..
hisilicon: Loading of kernel modules and initialization of the video system has started
mmz_start: 0x82000000, mmz_size: 32M
hisilicon: Get data from ipcinfo and set SENSOR as jxh42
hisilicon: Write detected jxh42 to U-Boot ENV
xxxx Invalid sensor type jxh42 xxxx
******* Error: There's something wrong, please check! *****
Starting majestic: OK
Welcome to OpenIPC
openipc-hi3518ev200 login:

Sounds like a hardware issue (RAM)

Столкнулся с аналогичной проблемой. Судя по всему связанна с работой автообновления через USB.
Как решение, для себя пересобрал u-boot с отключенной опцией  CONFIG_AUTO_USB_UPDATE, патч и готовый образ прикладываю.
0001-fix-booting-on-Lenovo-snowman-1080p.patch
u-boot-hi3518ev200-universal-patched.zip
Есть также обходной путь для штатного загрузчика OpenIPC, достаточно на SD карте создать файл autoupdate-kernel.img c размером более 3МБ,


Repo issue: The link in the "Running Verification Tests" section of Readme.md is broken

(Update) - Here: https://github.com/Esri/solutions-geoprocessing-toolbox#running-verification-tests

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Version used:
Environment name and version (e.g. Chrome 39, node.js 5.4):
Operating System and version (desktop or mobile):
Link to your project:

Verify in #513

Link works. Closing.


White artfact in round corners

Information
I'm trying to use haze to add some glass effect but for some reasons the corners of the tiles have some with line, it's not super noticiable in the image but you can see if you look at the corners, specially against the black background.

Haze version: 0.9.0-alpha04
Platform: Vanilla

Expected Behavior
Corners without any white lines.
Actual Behavior

Steps to Reproduce the Problem
This is my haze child setup:
.hazeChild(
    state = hazeState,
    shape = RoundedCornerShape(tileSettings.cornerRadius),
    style = HazeStyle(
        backgroundColor = MaterialTheme.colorScheme.primary,
        tint = MaterialTheme.colorScheme.primary.copy(0.3f),
        blurRadius = 5.dp,
        noiseFactor = 0.09f
    ),
)

What version of Android are you seeing this on?

I'm pretty sure this has been superceded by #287. We no longer need to support shape clipping, and now leave it to the normal Compose constructs for this. Closing this.


Document how NapariMPLWidget can be used by other plugins

NapariMPLWidget provides Matplotlib canvas and toolbar as a widget. It should be possible for external plugins to use this to avoid them having to create the canvas/toolbar themselves. How they can do this should be documented.

To pick up this discussion here - how would that work?
One approach for using the canvas within functions for napari would be something like this:
import NapariMPLWidget

def some_function(arg1: ImageData, arg2: float, napari_viewer: napari.viewer.Viewer = None) -> ImageData:
  # function does something here
  if napari_viewer is not None:
    widget = NapariMPLWidget()
    # plot something on the widget
    napari_viewer.window.add_dock_widget(widget)
  return result

@kevinyamauchi I think the napari_viewer argument is passed automatically if a function is exposed to the napari hook implementation...right?

Hello @jo-mueller!  for the widget spec, the viewer gets passed if one of the widget __init__  kwargs is either napari_viewer or typed as napari.viewer.Viewer. When the user
I think the best pattern for now is if the plugin is a widget plugin and the NapariMPLWidget (or one of its subclasses) is added as a widget to the plugins layout. Something like this:
from napari_matplotlib import ScatterWidget

class MyPlugin(QWidget):
    def __init__(self, napari_viewer: napari.viewer.Viewer):
        # set up some widgets
        my_widget = ...

        # set up the plot widget
        plot_widget =  ScatterWidget(napari_viewer)

        self.layout().addWidget(my_widget)
        self.layout().addWidget(plot_widget)

Yes, the above comment from @kevinyamauchi  is pretty much what I had in mind. Even though it's possible to use one of the "specialised" widgets, I'm imagining most people will just use NapariMPLWidget to get a blank Matplotlib figure. I'm going to try this out this afternoon with another plugin, so will report back on how it goes!

I was hoping that a plot plugin could somehow be created "on-the-fly" from a function that is exposed to magicgui. But creating a regular pyqt measurement plugin works, too.


Update dpy version

Update dpy version in requirements.txt as lot many old features started getting deprecated.

This library has been unmaintained for a while now, as I have quit discord development (hence also have not been keeping up with new discord API / discord.py updates). I wouldn't be surprised if anything broke. It's just here for people to use and modify / fork (also why it's not published).
You are more than welcome to make a fork and update things.
However I dont think updating d.py requirements from 1.7.3 min to 2.x would break anything, but at the same time its just a minimum requirement, and if you already have d.py installed prior it wont downgrade it or anything, but I'll check and update it


Wrong info in getUser

sometimes (not often) method getUser return incorrect data.
e.g. i call  getUser with user_id 123456789 but getting  info about another user with user_id 987654321.
But in next time when i call  getUser with user_id<PHONE_NUMBER> i getting true info.
somebody to face with it?

Are you sure that you correctly match requests with corresponding responses (for example, using @extra parameter in JSON interface)?

Returns information about a user by their identifier. This is an offline request if the current user is not a bot.
I don't quite understand that when the user I want to get is not a robot, the request is offline. Does that mean I query from a local database?
@levlam

Yes. There is no way to receive a user from the server just by its ID. See description of updateUser in https://core.telegram.org/tdlib/getting-started#handling-updates.


Encountered errors when reproducing lightning training example

🐛 Describe the bug
Tried to reproduce the liger kernel optimization on lighting trainer with deepspeed zero3 but encountered several errors.
Reproduce
script:
cd /examples/lightning/
python training.py --model Qwen/Qwen2-0.5B-Instruct --num_gpu 1 --max_length 1024 --strategy deepspeed

output:
[INFO] [real_accelerator.py:203:get_accelerator] Setting ds_accelerator to cuda (auto detect)
/opt/conda/envs/ptca/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_validation.py:118: UserWarning: onnxruntime training package info: package_name: onnxruntime-training
  warnings.warn("onnxruntime training package info: package_name: %s" % package_name)
/opt/conda/envs/ptca/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_validation.py:119: UserWarning: onnxruntime training package info: __version__: 1.18.0
  warnings.warn("onnxruntime training package info: __version__: %s" % version)
/opt/conda/envs/ptca/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_validation.py:120: UserWarning: onnxruntime training package info: cuda_version: 12.2
  warnings.warn("onnxruntime training package info: cuda_version: %s" % cuda_version)
/opt/conda/envs/ptca/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_validation.py:121: UserWarning: onnxruntime build info: cudart_version: 12020
  warnings.warn("onnxruntime build info: cudart_version: %s" % cudart_version)
/opt/conda/envs/ptca/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_validation.py:129: UserWarning: WARNING: failed to find cudart version that matches onnxruntime build info
  warnings.warn("WARNING: failed to find cudart version that matches onnxruntime build info")
/opt/conda/envs/ptca/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_validation.py:130: UserWarning: WARNING: found cudart versions: [12010]
  warnings.warn("WARNING: found cudart versions: %s" % local_cudart_versions)
2024-09-26 03:11:07.596978: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:485] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-09-26 03:11:07.611316: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:8454] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-09-26 03:11:07.615979: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1452] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-09-26 03:11:07.627834: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-09-26 03:11:08.472073: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
Seed set to 42
2024-09-26 03:11:09,359 root [WARNING] - Cannot import JIT optimized kernels. CUDA extension will be disabled.
Traceback (most recent call last):
  File "/Liger-Kernel/examples/lightning/training.py", line 289, in <module>
    train()
  File "/Liger-Kernel/examples/lightning/training.py", line 257, in train
    strategy = DeepSpeedStrategy(stage=3)
  File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/strategies/deepspeed.py", line 305, in __init__
    deepspeed.utils.logging.logger.setLevel(logging_level)
AttributeError: module 'deepspeed.utils' has no attribute 'logging'

I fixed above error by adding "import deepspeed" in training.py, but after that another error raised:
[rank0]: Traceback (most recent call last):
[rank0]:   File "/Liger-Kernel/examples/lightning/training.py", line 289, in <module>
[rank0]:     train()
[rank0]:   File "/Liger-Kernel/examples/lightning/training.py", line 285, in train
[rank0]:     trainer.fit(model, datamodule=data_module)
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/trainer/trainer.py", line 538, in fit
[rank0]:     call._call_and_handle_interrupt(
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/trainer/call.py", line 46, in _call_and_handle_interrupt
[rank0]:     return trainer.strategy.launcher.launch(trainer_fn, *args, trainer=trainer, **kwargs)
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/strategies/launchers/subprocess_script.py", line 105, in launch
[rank0]:     return function(*args, **kwargs)
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/trainer/trainer.py", line 574, in _fit_impl
[rank0]:     self._run(model, ckpt_path=ckpt_path)
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/trainer/trainer.py", line 945, in _run
[rank0]:     call._call_configure_model(self)
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/trainer/call.py", line 119, in _call_configure_model
[rank0]:     _call_lightning_module_hook(trainer, "configure_model")
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/lightning/pytorch/trainer/call.py", line 167, in _call_lightning_module_hook
[rank0]:     output = fn(*args, **kwargs)
[rank0]:   File "/Liger-Kernel/examples/lightning/training.py", line 76, in configure_model
[rank0]:     self.model = AutoLigerKernelForCausalLM.from_pretrained(
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/liger_kernel/transformers/auto_model.py", line 31, in from_pretrained
[rank0]:     return super().from_pretrained(
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py", line 564, in from_pretrained
[rank0]:     return model_class.from_pretrained(
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/transformers/modeling_utils.py", line 3838, in from_pretrained
[rank0]:     ) = cls._load_pretrained_model(
[rank0]:   File "/opt/conda/envs/ptca/lib/python3.10/site-packages/transformers/modeling_utils.py", line 4349, in _load_pretrained_model
[rank0]:     raise RuntimeError(f"Error(s) in loading state_dict for {model.__class__.__name__}:\n\t{error_msg}")
[rank0]: RuntimeError: Error(s) in loading state_dict for Qwen2ForCausalLM:
[rank0]:        size mismatch for model.embed_tokens.weight: copying a param with shape torch.Size([151936, 896]) from checkpoint, the shape in current model is torch.Size([0]).
[rank0]:        size mismatch for model.layers.0.self_attn.q_proj.weight: copying a param with shape torch.Size([896, 896]) from checkpoint, the shape in current model is torch.Size([0]).
[rank0]:        size mismatch for model.layers.0.self_attn.q_proj.bias: copying a param with shape torch.Size([896]) from checkpoint, the shape in current model is torch.Size([0]).

Versions
Environment Report:
Operating System: Linux-6.5.0-1025-azure-x86_64-with-glibc2.31
Python version: 3.10.14
PyTorch version: 2.4.1+cu121
CUDA version: 12.1
Triton version: 3.0.0
Transformers version: 4.42.4
deepspeed version: 0.15.0
liger_kernel version 0.3.0

i think it's related to the deepspeed model init method. When using deepspeed the model should be initialized in a context where all new tensor creation will have 0 shape and it's inside of deepspeed source to implement the sharding & broadcast. There could be something falling off either throughout liger diffs or deepspeed/HF new version release. Will TAL and get back to this issue asap.

So it was ignore_mismatch_shapes=True occasionally dropped and it has been fixed very recently in https://github.com/linkedin/Liger-Kernel/pull/263 😄  @ReginaZh you can try to install liger-kernel-lightly and it should fix your issue.

So it was ignore_mismatch_shapes=True occasionally dropped and it has been fixed very recently in https://github.com/linkedin/Liger-Kernel/pull/263 😄  @ReginaZh you can try to install liger-kernel-lightly and it should fix your issue. @shimizust do you think we can make a quick patch release for it 🤔 ?


Remove hardcoded courses and branches.

Have courses and branches directly scraped from Intranet.

@all-contributors Please add @sanjana2610 for code
Please add @rajkumaar23 for code, docs

@all-contributors Please add @sanjana2610 for code


Dcm kit general updates

I am pretty sure Renault contributed. Please adopt the License Notice accordingly.

I am pretty sure Renault contributed. Please adopt the License Notice accordingly.

Also all the license files for the pictures are empty.
Please add a license notice.


[BUG] - Synchronization is too slow

After 90% of the node data is synchronized, the synchronization speed becomes extremely slow

@satonz What does "slow" mean? An hour, a year? How long did it take for 90% of the data? How do you figure its 90%, is that 90% of the tip block height?
For the node to sync from scratch I expect syncing to take 1-2 hours on a standard desktop machine with a decent internet connection.

On my (above) standard desktop machine, synchronization hasn’t completed for a week or so and is stuck slightly above 23%, as reported in #2559. My personal definition of slow would be a decade or so, which is what it would take at the current pace. Something is broken in the communication with peers with lots of ...closed when reading data... messages.

@andrejpodzimek This is almost certainly a problem with your internet connection. With a decent internet connection, full sync from scratch should be under 4 hours.

Ok, your machine and network connection seem highly capable. My connection is nowhere near as good and neither is my machine. However, on my machine (or rather a VM running on my machine) I can download the whole chain in well under 4 hours.

Up until the ~23% that I managed to sync, it was quite fast and it looked like a full sync would be done in units of hours at most. But then something happened and it got stuck. It‘s unclear to me what that something could have been.
I’m considering a deletion of the whole database and a re-sync, but that’s definitely not a good way to find the root cause of this.

Have you tried just restarting it? There is a chance you initially connected to one or more very poor nodes. If you restart it, it is likley to pick up new difference peers.

Hi, I have the exact same issue after 25 million slots. I have tried:

Restarting everything
Starting all over again
Trying different networks
Connecting over 50+ different nodes (outcome: same speed)
Deleting db

None of them worked. It is clear that the speed at the beginning its fine but not optimal. As @andrejpodzimek when I reach ~23% it gets stuck... around 6 kb/s for me at least. I wrote on Cardano forum and the best idea was to sync with other nodes but as I said, every single one of them had the same speed.

Ok, need more information about this.

What version of the node are you running (version, git tag or git hash)?
How was it built?
Where are you getting the config file from?

@francisco-olea from experience to bootstrap a node the less peers you have in your topology file the quicker. I would suggest you try with one or two and see how it goes.

@erikd Yes, I’ve tried restarting it and also a number of other random trial-and-error steps, but nothing helped. My most recent tweak was to set valency to 16 (for relays-new.cardano-mainnet.iohk.io in mainnet-topology.json). Now, while I do see 16 connections in netstat -atpn, it’s still stuck. After my last database deletion and reset, it froze at 23.3% this time.

What version of the node are you running (version, git tag or git hash)?

1.26.1. (But 1.25.1 had the same issue. The only reason why I tried 1.26.1 was to make sure I’m not reporting something that’s already fixed.)

How was it built?

Using this package, just with s/1\.25\.1/1.26.1/ in PKGBUILD.

Where are you getting the config file from?

Also from the package; they are linked directly in the package overview. Their current source links are:

mainnet-topology.json (I now have valency set to 16 in this. I haven’t chantged anything else, also because I don’t have a block-signing node configured (yet).)
mainnet-config.json (I haven’t changed anything here or below.)
mainnet-shelley-genesis.json
mainnet-byron-genesis.json

@erikd Same as @andrejpodzimek .
Cardano-cli version: 1.26.1.
Package
I have only changed mainnet-topology.json to different addresses. @mrbrinker I put one at a time, still the same result. I have changed valency up to 4 but not 16 though.
Also I attach the sync speed timeline.

Yet another possible cause ruled out: Some systemd unit examples suggest an increase to the file descriptor limit. The default LimitNOFILE is 1024 on my system. So I’ve just set 32768 to try it out and verified with prlimit -p $(pidof cardano-node) that it took effect.
No change, unfortunately: Cardano actually uses way below 100 file descriptors most of the time (says lsof -p $(pidof cardano-node) and synchronization is still as stuck as ever before.

Is there anything suspicious in the logs?

Is there anything suspicious in the logs?

The usual warnings every now and then. Once they appear, they seem to be somewhat correlated with the slowness.
[charon:cardano.node.ErrorPolicy:Warning:258] [2021-04-02 22:52:27.48 UTC] IP xxx.xxx.xxx.xxx:39208 ErrorPolicySuspendPeer (Just (ApplicationExceptionTrace (MuxError MuxBearerClosed "<socket: 38> closed when reading data, waiting on next header True"))) 20s 20s
[charon:cardano.node.ErrorPolicy:Warning:258] [2021-04-02 22:52:32.52 UTC] IP xxx.xxx.xxx.xxx:50768 ErrorPolicySuspendPeer (Just (ApplicationExceptionTrace (MuxError MuxBearerClosed "<socket: 48> closed when reading data, waiting on next header False"))) 20s 20s
[charon:cardano.node.ErrorPolicy:Warning:258] [2021-04-02 22:52:38.58 UTC] IP xxx.xxx.xxx.xxx:57686 ErrorPolicySuspendPeer (Just (ApplicationExceptionTrace (MuxError MuxBearerClosed "<socket: 48> closed when reading data, waiting on next header False"))) 20s 20s

Otherwise there are lots of Notices (e.g. new tip) and very few Infos. The Chain extended messages are more frequent than anything else:
[charon:cardano.node.ChainDB:Notice:234] [2021-04-02 22:46:47.50 UTC] Chain extended, new tip: 3b3d44792ed5153623e57dc67e8deed010c7817563a55346192c742ac61386a1 at slot 25837316
[charon:cardano.node.ChainDB:Info:234] [2021-04-02 22:46:47.66 UTC] Block fits onto some fork: e2533a3cd8575334743b6e34222878acea7542b1a5fbea354197916d1acca56c at slot 25837314
[charon:cardano.node.ChainDB:Info:234] [2021-04-02 22:46:47.66 UTC] Valid candidate e2533a3cd8575334743b6e34222878acea7542b1a5fbea354197916d1acca56c at slot 25837314

Is there anything suspicious in the logs?

Actually, not sure why I haven’t grep’d for Errors explicitly. Here are some specimen:
[charon:cardano.node.DnsSubscription:Error:1977] [2021-04-02 22:04:10.98 UTC] Domain: "relays-new.cardano-mainnet.iohk.io" Application Exception: xxx.xxx.xxx.xxx:3001 ExceededTimeLimit (ChainSync (Header (HardForkBlock (': * ByronBlock (': * (ShelleyBlock (ShelleyEra StandardCrypto)) (': * (ShelleyBlock (ShelleyMAEra 'Allegra StandardCrypto)) (': * (ShelleyBlock (ShelleyMAEra 'Mary StandardCrypto)) ('[] *))))))) (Tip HardForkBlock (': * ByronBlock (': * (ShelleyBlock (ShelleyEra StandardCrypto)) (': * (ShelleyBlock (ShelleyMAEra 'Allegra StandardCrypto)) (': * (ShelleyBlock (ShelleyMAEra 'Mary StandardCrypto)) ('[] *))))))) (ServerAgency TokNext TokMustReply)
[charon:cardano.node.DnsSubscription:Error:2103] [2021-04-02 22:46:04.94 UTC] Domain: "relays-new.cardano-mainnet.iohk.io" Application Exception: xxx.xxx.xxx.xxx:3001 MuxError MuxBearerClosed "<socket: 68> closed when reading data, waiting on next header True"

Is there anything suspicious in the logs?

Just Info and Notice, I get ErrorPolicy:Notice:80 but still getting Chain extended.
[relay-no:cardano.node.DnsSubscription:Notice:113]  [2021-04-02 23:08:30.93 UTC] Domain: "relays-new.cardano-mainnet.iohk.io" Connection Attempt Start, destination <IP_ADDRESS>:3001
[relay-no:cardano.node.ChainDB:Notice:61]  [2021-04-02 23:08:30.94 UTC] Chain extended, new tip: 234929eb62e6ef12471bb4d5dd2949c497e7bdf79c9f29291bd284794a8fd141 at slot 25837901
[relay-no:cardano.node.DnsSubscription:Notice:98]  [2021-04-02 23:08:30.96 UTC] Domain: "relays-new.cardano-mainnet.iohk.io" Connection Attempt End, destination <IP_ADDRESS>:3001 outcome: ConnectSuccessLast
[relay-no:cardano.node.ErrorPolicy:Notice:80]  [2021-04-02 23:08:30.96 UTC] IP <IP_ADDRESS>:3001 ErrorPolicySuspendConsumer (Just (ConnectionExceptionTrace (SubscriberError {seType = SubscriberParallelConnectionCancelled, seMessage = "Parallel connection cancelled", seStack = []}))) 1s

I am currently synching my node from scratch. It has been running for about 6 hours and is currently at epoch 237 (about 20 epoch until it has caught up to the tip). This is slower than I remember it, but is has been some time since I synced a node from scratch,
Also is this related? https://github.com/input-output-hk/cardano-node/issues/2222

I am currently synching my node from scratch. It has been running for about 6 hours and is currently at epoch 237 (about 20 epoch until it has caught up to the tip). This is slower than I remember it, but is has been some time since I synced a node from scratch.

Are you running cardano-cli version 1.26.1?

Yes 1.26.1 of both the node and cli. By the way see https://github.com/input-output-hk/cardano-node/issues/2559 .

Yes 1.26.1 of both the node and cli. By the way see #2559 .

Yeah, I followed #2559 and got
CARDANO_NODE_SOCKET_PATH=~/Pool/relay/db/node.socket cardano-cli query tip --mainnet
{
     "epoch": 257,
     "hash": "35c1c274c45b0edb1f22935aee04eb3cb1eb756ec7b1c0a3157cf4cbee7adb0c",
     "slot": 25924913,
    "block": 5545895
}

so is fully synced. Thanks!

Ok, closing this. Thanks1


Go through all stuns and flag them as such

In order to allow strong dispels (e.g. abaddon's aphotic shield) to dispel them.

irrelevant through usage of "modifier_stunned"


MSRV raised to 1.34.0 in 1.0.10-11

This is minimally just and FYI for maintainers and users, if MSRV bumps such as this in patch releases are considered acceptable here.
When compiling with rust rustc 1.28.0 (9634041f0 2018-07-30) 1.28.0-x86_64-unknown-linux-gnu:
error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  --> /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.11/src/ffi.rs:96:26
   |
96 |     const ALIGN: usize = std::mem::align_of::<usize>();
   |                          ^^^

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
   --> /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.11/src/ffi.rs:111:41
    |
111 |             .and_then(|i| i.checked_add(std::mem::size_of::<usize>()))
    |                                         ^^^

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
   --> /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.11/src/ffi.rs:388:30
    |
388 |         pub type AllocSize = libc::size_t;
    |                              ^^^^

error[E0658]: use of unstable library feature 'try_from' (see issue #33417)
  --> /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.11/src/ffi.rs:47:9
   |
47 |     use std::convert::TryFrom;
   |         ^^^^^^^^^^^^^^^^^^^^^

error[E0658]: use of unstable library feature 'try_from' (see issue #33417)
   --> /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.11/src/ffi.rs:109:27
    |
109 |             .and_then(|i| usize::try_from(i).ok())
    |                           ^^^^^^^^^^^^^^^

error: aborting due to 5 previous errors

With rust 1.31.0-x86_64-unknown-linux-gnu:
error[E0658]: use of unstable library feature 'try_from' (see issue #33417)
  --> /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.11/src/ffi.rs:47:9
   |
47 |     use std::convert::TryFrom;
   |         ^^^^^^^^^^^^^^^^^^^^^

   Compiling parking_lot v0.7.1
error[E0658]: use of unstable library feature 'try_from' (see issue #33417)
   --> /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.11/src/ffi.rs:109:27
    |
109 |             .and_then(|i| usize::try_from(i).ok())
    |                           ^^^^^^^^^^^^^^^

Where std::convert::TryFrom isn't stable until rust 1.34.0.
If instead I downgrade to 1.0.9, then it compiles with rust 1.28.0 (and possibly lower).

Thanks for the report! This crate supports the current stable and last stable for the latest version, so this is intended. If you'd like to send a PR though to build on older versions such a PR is always welcome!


hoistedPackages accepts root but does not pass it to every sub-function

I know this because I tried to call hoistedPackages with a path to a cousin directory (I was not in a monorepo at the time) and I got an error about "could not find lerna manifest upwards from current directory"

> {
  _tag: 'Left',
  left: {
    type: 'cannot find lerna manifest upwards from known path',
    path: '/home/ericcrosson/workspace/scratch/researh-hoisted-packages'
  }
}

> {
  _tag: 'Left',
  left: {
    type: 'cannot find lerna manifest upwards from known path',
    path: '/home/stuff/research-hoisted-packages'
  }
}


Bump to 2.6.1

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Thanks @chengzhuzhang, the build is passing so I will go ahead and merge.

Thanks for the info @xylar. I ran that command in another feedstock PR and it said something like "nothing to do", so I was under the impression that you only run it if there are changes to the PR.
I now see that it is also a way to validate that the package builds before merging.

I now see that it is also a way to validate that the package builds before merging.

I guess that's right in a certain sense.  There's a software called conda-smithy that keeps track of updates to all of the feedstocks.  It has total control of everything outside of the recipe directory and the conda_forge.yaml file.  You aren't supposed to change anything outside of those two.  When you rerender, you let conda-smithy update all the other files.  Sometimes, that's based on changes you made to the recipe (e.g. adding new dependencies that are pinned to specific versions on conda-forge, like hdf5).  Sometimes, it's updates to things like the docker images it uses, the access tokens to the CI services, and who knows what else.  Basically, you never know what you're going to get until you do the rerender.
You can rerender locally but I don't really recommend it.  It's easier to let the bot take care of it with the comment I mentioned above.


HDRP Support?

I know this is probably much to ask on such an old repo but I've been fiddling around with different solutions all day and this has been the best one so far, the only issue being I'm trying to use it in a HDRP project and the boids shader just isn't compatible, an hdrp version would be very nice or at least some direction for how I could go about doing it myself.

Hello there,
I would suggest just trying to make the folder 2-GPU_Boids_Compute/ works as it's pretty minimalistic and easy to translate to HDRP.
The shader itself is pretty small and I'm guessing the only line that needs to change are the headers, probably the #include "UnityCG.cginc" that needs another path or something. I cannot help on that account as I'm not trying to dive into HDRP as it's frequently updated and everything breaks all the time.


Removed Artifactory repo from the default repo list

artifactory.com has been deprecated recently and is no longer working as of June 30, 2017. see https://www.jfrog.com/knowledge-base/deprecation-of-artifactoryonline-com-domain
The alternative option is to use jfrog.io

Thanks @leiwangx. Could you please fill out the CLA on http://druid.io/community/cla.html so we can accept your patch?

@gianm he's covered by MMX

@drcrallen ah, thanks.


New release?

Could you please cut a new release? I'm currently using my own built because of #123 and #121
Thanks!

sure I can do this tonight/tomorrow night. Does goofys have enough users to warrant a mailing list yet?

Awesome, thanks!
Personally, I'd prefer a twitter account that I could follow.

I already have a twitter account (@kahingcheung) but understandably it's a bit noisy. I can look into having one specific for goofys. Sadly @goofys is taken

I've signed up for @s3goofys

fixed via f8d668c29bbf43aa36acea68e05b493f16f5e990


Add a better 'What is RKE2?'

I believe the introduction page is really lacking a basic "What is RKE2?"..
I would be in favor of creating an additional header with "What is RKE2?". Explaining to people who are new to Kubernetes and just want to know what to expect from RKE2 in term of features and what problem it tries to solve.
The current (2 years old) introduction is not really saying anything about what RKE2 does and can do:

To meet these goals, RKE2 does the following:

Provides defaults and configuration options that allow clusters to pass the CIS Kubernetes Benchmark v1.6 or v1.23 with minimal operator intervention
Enables FIPS 140-2 compliance
Regularly scans components for CVEs using trivy in our build pipeline

I think k3s has a better introduction: https://docs.k3s.io/
Thanks.
Kind regards,
Melroy van den Berg

This sort of thing is owned by the SUSE Product Manager to a greater extent than K3s, since K3s is a CNCF project. Glad to point them at this conversation though!


[Mobile] Caret is obliterated by colored text background

(Observed on Android)
Actual
Caret appears behind colored text background, making the caret partially visible.

Expected
Caret appears on top of colored text background.
Thank you.

code is here

This is basically how to add background color for TextSpan that will not be obliterated by cursor
@florianh01 @friebetill  any thought?

Hmm, it is probably some setting when buildToolbar

Likely the canvas.drawRRect method

You are right
Need to figure out how canvas works

Probably has to do with LayerLink


fix: stop using squared icon for github and twitter

Fix #1249

I changed the icons manually. Let me know if you think it would worth the shot to change the "twitter_url", "github_url" bhavior instead
added some colors (because why not ?)

I found this https://simpleicons.org/icons/pypi.svg to replace the icon for pypi. Do you know how to use custom svg and use the same coloring as the fa icons ?

thanks to your guidance I managed to get closer to a solution:

I added the all.min.js script from fontawesome to our webpack macros
now all fontawesome icons are transformed into svg
I created a small script to add the svg of the pypi logo as explained in fa issue: https://github.com/FortAwesome/Font-Awesome/issues/13079

I now face a strange issue, icon size from the header is reduced. I'm woking on it.

Cleaning is done and I'm satisfied with the tests. Here is a summary of the changes so far:

add the js file from fontawesome distrib o rely on SVG generated icons
add a custom icon to our doc
resize all header navbar icon to fa-lg
align the theme-switcher styling on the other icons

it works fine on my computer. feel free to merge whenever your satifyed with the icon


[5.7-04182022][Distributed] Retain ad-hoc decodeNextArgument in distributed thunk

Cherry-pick of https://github.com/apple/swift/pull/42252

Explanation:

SIL has to force emission of decodeNextArgument and its retainment,
so IRGen can reference it in distributed function accessor, otherwise it
wouldn't be possible to use any type expect to a class to implement
a DistributedInvocationDecoder protocol which limits the use of the
feature significantly.

Scope: Types implementing  DistributedInvocationDecoder protocol.

Main Branch PR: https://github.com/apple/swift/pull/42252

5.7 Branch PR: https://github.com/apple/swift/pull/42451

Resolves: rdar://88211172

Risk: Very low

Reviewed By: @ktoso, @hborla

Testing:  Added regression test-cases to the suite.


Auto polling for build status

Adds settings to allow auto polling of build status (defaults: true, 60 second intervals). Can use settings from the global vscode settings or from ./.vscode/settings.json file on a project-by-project basis. Adds feature from #18

Seems solid, thank you very much!

...and published as 1.1.0!

You're absolutely welcome, and thanks :)


[SPARK-40768][SQL] Migrate type check failures of bloom_filter_agg() onto error classes

What changes were proposed in this pull request?

In the PR, I propose to use error classes in the case of type check failure in Bloom Filter Agg expressions.
Why are the changes needed?

Migration onto error classes unifies Spark SQL error messages.
Does this PR introduce any user-facing change?

Yes. The PR changes user-facing error messages.
How was this patch tested?

build/sbt "sql/testOnly *SQLQueryTestSuite"
build/sbt "test:testOnly org.apache.spark.SparkThrowableSuite"
build/sbt "test:testOnly *BloomFilterAggregateQuerySuite"

cc @MaxGekk

@lvshaokang Isn't the failure related to your changes?
Different files: ['base_pb2.pyi', 'commands_pb2.pyi', 'expressions_pb2.pyi', 'relations_pb2.pyi', 'types_pb2.pyi']
Generated files for pyspark-connect are out of sync! Please run ./connector/connect/dev/generate_protos.sh
Error: Process completed with exit code 255.

@MaxGekk No, It seems to be unrelated, I don't know why it would lead to this, and I tried retrying CI, but it still reports an error.

@HyukjinKwon @zhengruifeng @grundprinzip Should we worry about the failures https://github.com/apache/spark/pull/38315#issuecomment-1285894438 or can just ignore them?

@HyukjinKwon @zhengruifeng @grundprinzip Should we worry about the failures https://github.com/apache/spark/pull/38315#issuecomment-1285894438 or can just ignore them?

In theory, of you merge master into your branch this should go away as current master should be in sync.

In theory, of you merge master into your branch this should go away as current master should be in sync.

I have merged the master branch into my branch and push it, wating the CI complete.

Can one of the admins verify this patch?

@MaxGekk CI run successful. Please take a look, thanks.

+1, LGTM. Merging to master.
Thank you, @lvshaokang.

@HyukjinKwon @zhengruifeng @grundprinzip Should we worry about the failures #38315 (comment) or can just ignore them?

that was due to mypy-protobuf upgrade, now the version was pined in  https://github.com/apache/spark/commit/0643d02e4f03cdadb53efc05af0b6533d22db297


bug(tekla): Report Log renders in DUI as a text blob

Side effect is that the report also doesn't scroll.

Closing this ticket as we are moving to Jira to reduce noise. You can access it there.


RSeQC terminology

Great work, I might be extending or at least re-purposing some of it soon. Just a comment about the RSeQC results in output.md: inner distance should not be confused with insert size. See here for disambiguation by @tseemann, parly quoted below. One might of course argue it is a local variable which can be called as one pleases ;-)
Mind the gap (by @tseemann)
There is a lot of confusion about the gap of unknown bases. You will encounter terms like "insert size", "fragment size", "library size" and variations thereof. The term "insert" comes from a time before NGS existed, when cloning DNA in E.coli vectors was standard business.
PE reads      R1--------->                    <---------R2
fragment     ~~~========================================~~~
insert          ========================================
inner mate                ....................

The main confusion is with "insert size". The name itself suggests it is the unknown gap because it is "inserted" between R1 and R2, but this is misleading. It is more accurate to think of the insert as the piece of DNA inserted between the adaptors which enable amplification and sequencing of that piece of DNA. So the "insert" actually encompasses R1 and R2 as well as the unknown gap between them. The name for the gap itself is better named "inner mate distance" because it is self-descriptive and can vary depending on what read lengths you sequenced a DNA library with.

Thanks @rsuchecki! This is just my development fork, so I've moved your issue to the main repo. We can continue this there.. 👍


Code blocks in notebooks are not syntax highlighted when viewing or editing

Azure Data Studio Version: 1.33.1
OS Version: Windows 10

Steps to Reproduce:

Create new notebook
Create new text cell
Switch to Split View
Add following markdown text (remove the 2 extra set of tabs used here so markdown will show correctly in the ticket)

    **SQL**:

    ```sql
    use master
    select * from sys.tables
    ```

Notice how the syntax highlighting works in the mardown editor, but does not work in the preview.  The text is also not "syntax highlighted" when leaving the text cell.

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

Similar issue with other languages:


Coinbase validation after block #305000

Maybe it happens only to me, but after block #305000 the validation Block#coinbase_value fails.

Thanks for bringing it up, I'll look into it. Need to sync a fresh blockchain though, so it's gonna take a bit...
You're using the utxo backend on postgres?

Does this fix your issue? Still couldn't test it with the real blockchain, but it would make sense...

Updated and started over but no change:
INFO  network: <IP_ADDRESS>:8221 << getblocks:<PHONE_NUMBER>000000142bb90561e1a907d500bf534a6727a63a92af5b6abc6160
WARN  network: ValidationError storing block<PHONE_NUMBER>00000050ad924af73fd35698f68841e1658536e4fce99ec9262423: block error: context check 2 - coinbase_value failed

and all blocks afterwards are orphans. I've even tried:
delete from utxo where blk_id in (select id from blk where height > 304000);
delete from blk where height > 304000;

and resumed the node, but after 1000 blocks the problem is still same.

Hmm, strange... My node finally synced to that block, and went over it without any problems.
I'm on commit 5f508d35bf2e42e355446d8ed11304dff0b88be5 now, with ruby 2.1.1p76 and postgres 9.1.14 on debian 7.8 (wheezy). What is your environment?
Btw. just deleting the utxo records can't work, you'd also need to restore the old ones, or you'll get missing prev_outs for sure...

Ah, now I could reproduce it - somewhat, because for me it fails in the transactions_context/prev_out check, but in the same block...
DEBUG storage: => main (305001)
DEBUG storage: validating block context<PHONE_NUMBER>00000050ad924af73fd35698f68841e1658536e4fce99ec9262423 (349200 bytes)
.....
DEBUG storage: validating tx context 66449be322135da722bcfc0e3de10971ca9a368ec2493dafdc0ec9c9631ee8a7 (191 bytes)
 WARN storage: prev out f049ed1baf9a7a8fe91a1d534690e9478df340a4f568242db39c225232c9dcdf:0 missing
 INFO storage: tx error: context check 0 - prev_out failed
 WARN network: ValidationError storing block<PHONE_NUMBER>00000050ad924af73fd35698f68841e1658536e4fce99ec9262423: block error: context check 4 - transactions_context failed


Raw data display and filter/search functionalities?

I can see many types of statistics in the html report. However, does it has a way to view one specific record or maybe do a search or time range filter. Sometimes we get interested when watching the charts and want to see some particular records.

@vStone can you please elaborate what you mean with access to raw data and files and how goaccess should display handle the data/file?

@allinurl  A simple panel that would allow access to a file (scroll through) and tail functionality. For example php/apache/... error logs. Or even a custom application log.


Update import reference path

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Resolves: #28
Summary:
This commit updates the reference path to auro-accordion from the incorrect ./dist path to the ./src path.
The reason why this was set to ./dist and the element still operates as expected locally is unknown.
On branch dsande/hotfix/refpath/28
Changes to be committed:
modified:   src/auro-sidenavsection.js
Type of change:
Please delete options that are not relevant.

[ ] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[x] Other (bug fix)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 2.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


1.0.0-rc3 update: use old plugin value

AFAICT sqldelight/RELEASE_CANDIDATE.md has an incorrect instruction; the sqldelight plugin statement:
apply plugin: 'com.squareup.sqldelight.android'
should be replaced with the legacy (i.e. no change required from 0.6.1/0.7.X/0.9.0):
apply plugin: 'com.squareup.sqldelight'

Also (again AFAICT) this statement isn't necessary:
apply plugin: 'org.jetbrains.kotlin.android'

Sounds good! Mind submitting a PR for those changes?
On Sun., Nov. 25, 2018, 5:06 a.m. Steve M<EMAIL_ADDRESS>wrote:

Also (again AFAICT) this statement isn't necessary:
apply plugin: 'org.jetbrains.kotlin.android'
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/square/sqldelight/issues/1056#issuecomment-441428925,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABmQwO_8NP_DD8oxo-3QKXp_NVNBLeYaks5uymu3gaJpZM4YxzLo
.

https://github.com/square/sqldelight/pull/1058


bug when re-loading 10 or more source vocabs

I believe there is a bug in vocab.load_source_vocabs that is apparent only when 9 or more source-factors are in use (10+ total source vocabularies). The prepared source vocabularies for each of the source-factors are ordered by integer labels (vocab.src.0.json, vocab.src.1.json, vocab.src.2.json etc..) However, when these source vocabs are loaded from a sockeye-prepared data directory, they are sorted in alphabetic/string order, which means that vocab.src.10.json will come before vocab.src.2.json and so forth. This means that the vocabularies originally prepared by sockeye.prepare-data will not match the re-loaded vocabularies (see error below).
def load_source_vocabs(folder: str) -> List[Vocab]:
    """
    Loads source vocabularies from folder. The first element in the list is the primary source vocabulary.
    Other elements correspond to optional additional source factor vocabularies found in folder.
    :param folder: Source folder.
    :return: List of vocabularies.
    """
    return [vocab_from_json(os.path.join(folder, fname)) for fname in
            sorted([f for f in os.listdir(folder) if f.startswith(C.VOCAB_SRC_PREFIX)])]

Specifically, the issue arises when I try to resume training on a model where I'm using the --prepared-data flag, giving the following error:
Traceback (most recent call last):
  File "/home/rrudinger/.conda/envs/sockeye10/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/rrudinger/.conda/envs/sockeye10/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/rrudinger/.conda/envs/sockeye10/lib/python3.6/site-packages/sockeye/train.py", line 966, in <module>
    main()
  File "/home/rrudinger/.conda/envs/sockeye10/lib/python3.6/site-packages/sockeye/train.py", line 832, in main
    train(args)
  File "/home/rrudinger/.conda/envs/sockeye10/lib/python3.6/site-packages/sockeye/train.py", line 886, in train
    output_folder=output_folder)
  File "/home/rrudinger/.conda/envs/sockeye10/lib/python3.6/site-packages/sockeye/train.py", line 271, in create_data_iters_and_vocabs
    "Prepared data and resumed model source vocab %d do not match." % i)
  File "/home/rrudinger/.conda/envs/sockeye10/lib/python3.6/site-packages/sockeye/utils.py", line 121, in check_condition
    raise SockeyeError(error_message)
sockeye.utils.SockeyeError: Prepared data and resumed model source vocab 2 do not match.

Edit: Assuming that all sockeye-created source vocabs are of the form *.N.json where N is an integer, then I think the following would fix the issue:
def load_source_vocabs(folder: str) -> List[Vocab]:
    """
    Loads source vocabularies from folder. The first element in the list is the primary source vocabulary.
    Other elements correspond to optional additional source factor vocabularies found in folder.
    :param folder: Source folder.
    :return: List of vocabularies.
    """
    return [vocab_from_json(os.path.join(folder, fname)) for fname in
            sorted([f for f in os.listdir(folder) if f.startswith(C.VOCAB_SRC_PREFIX)], key=lambda x: int(x.split('.')[-2]))]

Great catch, thank you! I can take a look in making the sorting cover the # of source factors > 10 case.

 I'm not currently working on a developer branch; just wanted to bring attention to this. The one-line modification above should do the trick. Thanks again!

Ok, I'll do the change then. Thanks!


Problems compiling listener_c and talker_c for BOARD=samr21-xpro

Hi @astralien3000,
First of all, great job porting ros2 on microcontrollers with RIOT.
Yesterday when I was trying to compile listener_c and talker_c for smar21-xpro I was experimenting the next error
/home/jlamperez/Workspace/riot-ros2/src/rmw/error_handling.c:27:38: error: __emutls_t.__rmw_error_state causes a section type conflict with __rmw_error_state
 RMW_THREAD_LOCAL rmw_error_state_t * __rmw_error_state = NULL;
                                      ^
/home/jlamperez/Workspace/riot-ros2/src/rmw/error_handling.c:27:38: note: '__rmw_error_state' was declared here
/home/jlamperez/Workspace/riot-ros2/RIOT/Makefile.base:81: recipe for target '/home/jlamperez/Workspace/riot-ros2/examples/talker_c/bin/samr21-xpro/rmw/error_handling.o' failed
make[3]: *** [/home/jlamperez/Workspace/riot-ros2/examples/talker_c/bin/samr21-xpro/rmw/error_handling.o] Error 1
make[3]: Leaving directory '/home/jlamperez/Workspace/riot-ros2/src/rmw'
/home/jlamperez/Workspace/riot-ros2/RIOT/Makefile.base:20: recipe for target 'ALL--/home/jlamperez/Workspace/riot-ros2/src/rmw' failed
make[2]: *** [ALL--/home/jlamperez/Workspace/riot-ros2/src/rmw] Error 2
make[2]: Leaving directory '/home/jlamperez/Workspace/riot-ros2'
/home/jlamperez/Workspace/riot-ros2/RIOT/Makefile.base:20: recipe for target 'ALL--/home/jlamperez/Workspace/riot-ros2' failed
make[1]: *** [ALL--/home/jlamperez/Workspace/riot-ros2] Error 2
make[1]: Leaving directory '/home/jlamperez/Workspace/riot-ros2/examples/talker_c'
/home/jlamperez/Workspace/riot-ros2/examples/talker_c/../../RIOT/Makefile.include:297: recipe for target 'all' failed
make: *** [all] Error 2

The command I used inside riot-ros2/examples/talker_c was
make RMW=rmw_mqtt BOARD=samr21-xpro

Do you know how to solve it to allow me to flash the board?
Thank you for your time.
Jorge

Hi @jlamperez,
Thank you for your feedback !
I'm sorry, currently the rmw_mqtt version is not very stable. Which version are you using ? mqtt is not likely to work on the master branch. You can use the branches v0.0 or v0.1 for it.
If you were already on these versions, I will try to investigate. What is your OS ?

Hi @astralien3000,
Thank you for answer to me, right now I am using the master branch of your repository and same happens to me when I try ndn.
I will try with the branches you say me.
My OS is Ubuntu 16.04.

I don't have Ubuntu to test right now, only Fedora. I can't get the same error on Fedora. I will try to get an Ubuntu.
Just to know, what is your version of arm-none-eabi-gcc ?
Also, it seems like the rmw_mqtt version was already broken in v0.1 ^^", only v0.0 can currently compile with mqtt.

Just to know, what is your version of arm-none-eabi-gcc ?

I am using arm-none-eabi-gcc (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease)

Ok, this version is supposed to be ok for RIOT, but maybe too old for some ros2 code.
First, you could try to remove the bin directory in the example, to ensure there is no error from previous compilation, and retry make BOARD=samr21-xpro.
If it fails again, you can try to update the arm-none-eabi toolchain.

Well, the previous link is not so clear.
I could make it work on ubuntu 16.04 :
# Remove old toolchain
sudo apt remove gcc-arm-none-eabi
sudo apt autoremove

# Install new toolchain
sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt install gcc-arm-embedded

Does it help ?

Hi @astralien3000
I updated the arm-none-eabi toolchain to version 6.3 and it worked.
Thanks!

You're welcome !


[BUG] THE RGBA COLOR FORMAT IS GIVING WRONG COLORS

var redColor = { red: 255, green: 0, blue: 0, alpha: 1 };

const cell1 = sheet1.getCell(1, 1);

cell1.backgroundColor = redColor;

await sheet1.saveUpdatedCells();

this should give the corresponding cell a red color instead of it a black color

@iamrishan you should provide RGBA colors between 0 and 1.
Try this: https://www.rapidtables.com/convert/color/hex-to-rgb.html

Oh, that's why... Thanks, i think it doesn't mention anywhere that the package uses RGB 0-1 values

 this is cool if you wanna grab specific colors RGB 0-1 values

its definitely not obvious in google's docs. Would probably be good to clarify on the docs site and in the jsdoc type comments... Always open to PRs! otherwise will add in my next round of improvements...
Thanks


Make clear that Windows is not supported for multi-node grid

Windows on a multinode system most likely doesn't won't work, and isn't going to be fixed:
https://trello.com/c/uR1VOttF/623-omero-node-should-be-refactored

@hflynn Removed

:+1:

I'll be removing all the Windows sysadmin content for 5.3 anyway, I'll just add cleaning up the rest of this page to my list.


Better support for bash aliases from fig run

I want to provide some complex alias for use with fig run. I therefore added something like this in my Dockerfile:
FROM php:5.6-apache
RUN echo "alias myalias='some_lengthy_and_complex_command_with \$ENV_VARS'" >> /etc/bash.bashrc

I've double checked with docker exec -ti web bash, that the alias is written correctly and it really works: I can use the alias there.
But if I try to use it with fig run it always fails:
fig run web myalias
fig run web bash -c 'myalias'

The alias is not even shown with fig run web bash -c 'alias'. Any idea, how to solve this?
UPDATE: The alias is also available from the shell, that opens with fig run web bash. But I need to run the alias non-interactively.

Ok, I think I found the answer here:
http://stackoverflow.com/questions/1615877/why-aliases-in-a-non-interactive-bash-shell-do-not-work
So closing this again for now.


Epic - Mobile app upload

Features/Capabilities
ios and android app support
evidence upload
upload eyewitness account
Technical Requirements
mobile UI
live streaming
Roles Needed
Designers ux/ui
Mobile App Developer
A data protection person/reviewer
Upload reviewer
Leveraging what other project have done

Similar issue being worked under https://github.com/Call-for-Code-for-Racial-Justice/Incident-Accuracy-Reporting-System/issues/96.


How do I recieve all the unread messages. i just get the messages for the person i stayed on

That's how the design is right now. :/


Clear from pwsh is not working

Not sure if it is supported but

It looks like it's having a disagreement with the redirected console input or output. We should implement a clear gesture at the REPL level. See: #19.


question about syncing

Apologies if this is a silly question: I like so much about Errands. However, I don't really require it so much for my mobile device, and in any case would rather not go to the trouble of installing NextCloud; instead, would rather simply use Syncthing to keep my my desktop and laptops, in sync via a Raspberry Pi, which works very nicely for the dozen directories for which I use it. However, for some reason SyncThing isn't able to copy ANYTHING from ~/.var/app/io.github.mrvladus.List to another device. Am I missing something? Or would this rather a Syncthing question?

It's probably something to do with Flatpak folders permissions. It's better to ask it at Syncthing issues

Mod there pointed out Flatpak apps are sandboxed from one another by default - so I used Flatseal to grant access to ~/.var/app/io.github.mrvladus.List, seems to be working so far. Hope this helps someone else!


New releases not being distributed on all installations

Acceptance criteria:

[ ] Investigate why new releases are not being distributed on all installations

Slack Thread which explains why it's currently not applying releases in MC's

Related threads:

https://gigantic.slack.com/archives/C07KSM2E51A/p1727788515429729
https://gigantic.slack.com/archives/CLPMFRVU6/p1727788936150309?thread_ts=1727788228.473829&cid=CLPMFRVU6

Couple things going on here:

At least on enigma some / all of the Release CRs were applied manually and are thus missing the required labels so the App is failing to install or upgrade. We need to manually clean this up but we should create an alert for this first so that we can catch this in advance in the future.
We are using the git commit sha as the App version instead of actual semver versions. Because of this, the "latest" version is being incorrectly worked out as the highest alphabetical sha version instead of the latest published. This means if a sha is alphabetically lower than the previous release's sha it wont be deployed to ANY MC.

I just manually bumped the release-capa app version in the capa-app-collection so the latest CAPA Release CRs get deployed to CAPA MCs: https://github.com/giantswarm/capa-app-collection/commit/260deaa286bc18f4badd31094a2d15de148143b5

Releases are now deployed via GitOps on CAPI MCs. See the following PRs for details:

https://github.com/giantswarm/management-cluster-bases/pull/162: This deploys the releases repository as GitRepository to every cluster and adds a generic way to easily include provider releases in MC configurations.
https://github.com/giantswarm/management-cluster-bases/pull/163: This PR by default includes one MC's provider releases in its configuration. This Kustomization is already being included everywhere in <provider>-management-clusters, so it simply deploys the provider specific releases Kustomization to every MC.
https://github.com/giantswarm/management-cluster-bases/pull/164: Here I enabled pruning for the collection Kustomization as a preparation for removing the releases-<provider> app from app collections.
https://github.com/giantswarm/releases/pull/1473: Here I add the helm.sh/resource-policy: keep annotation to Release CRs so they stay around once the releases-<provider> app gets removed from an MC.
Afterwards I removed the releases-<provider> apps from app collections:

https://github.com/giantswarm/capa-app-collection/commit/f7c9f34e78a14b9332205d22edfa1b8d555b7f23
https://github.com/giantswarm/capz-app-collection/commit/d248e83433c3f5d9961a1f466e4fd7a1f6bc0099
https://github.com/giantswarm/vsphere-app-collection/commit/96f72ca4de8836417335af117ca48fe28fe18320

At this point the releases-<provider> apps got removed from MCs. I already checked them and verified Release CRs are still around and managed by Flux. ✅

Now we only need to remove the helm.sh/resource-policy: keep annotation again with this PR https://github.com/giantswarm/releases/pull/1477 and enable pruning for the releases-<provider> Kustomizations so archived Release CRs are getting removed from MCs in this PR https://github.com/giantswarm/management-cluster-bases/pull/165.

And with this little PR I also updated mc-bootstrap: https://github.com/giantswarm/mc-bootstrap/pull/1055


[4.0] [Type checker] Don't allow type variables to bind to dependent members.

Explanation: Addresses a type inference regression introduced in Swift 4 involving certain same-type constraints among two interdependent generic type parameters.
Scope: The behavioral change affects code with a set of interesting same-type constraints (we've seen two user-reported instances of this), although the solution is a more general improvement to the type checker.
Radar: rdar://problem/32697033 (+ dupes)
Risk: Low; in theory we're delaying some type variable bindings that could cause type inference failures, but is appears to be highly unlikely
Testing: Compiler regression testing, new tests, source compatibility suite

@swift-ci please test


[WASM] Run RustPython WASM from another language?

I would like to be able to load the RustPython WASM file into another language to execute Python code and retrieve Python results. I've looked at the WASM module produced by the following, and it appears the only export is the main function.
cargo build --release --target wasm32-wasi --features="freeze-stdlib"

Is main the only way to interact with the WASM module, or is there another way to use it that allows you to get results back from a function call? If using main is the only way, how do command-line arguments get passed in?

Did you build rustpython-wasm crate?
cd wasm/lib and try to build there. I never tried wasm stuff myself but it must have more stuffs.
cc @coolreader18

Hey @kesmit13, sorry for pinging you but it looks like you could make it work. Could you give me a pointer how you do it?

@harisraharjo I ended up going a different route. We are now using CPython compiled to WASM. See this project https://github.com/singlestore-labs/python-wasi.


Add metrics to monitor store disk usage

The DefaultStorageProviderConfiguration has "storage.dir". You can just use it.

This will introduce "filer" dependency in to metrics-core which I don't think it is worth. Maybe I need to think about use default "indy.home" directly


Added hostname to command line arguments

Merged this in by hand. It's now on master. Will go in with the next release. Thanks!