[date] build failure

Operating system
Windows 11 Home 22H2 (10.0.22621.3155)
Compiler
MSVC, MinGW64 GCC
Steps to reproduce the behavior
1. Install latest vcpkg
2. Create a `vcpkg.json` manifest with a `date` dependency
3. Create a `CMakeLists.txt` with minimal C++ project, `find_package(date CONFIG REQUIRED)` and `target_link_libraries(${PROJECT_NAME} PRIVATE date::date)`

Failure logs
Note these lines in particular:
[cmake] warning: The folder /include is empty or not present. This indicates the library was not correctly installed.
[cmake] error: Found 1 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile: C:\msys64\opt\vcpkg\ports\date\portfile.cmake

MSVC 19.39.33519.0:
[main] Configuring project: rustSatelliteDish
[driver] Removing C:/msys64/home/bensh/projects/rustSatelliteDish/out/build/x64-windows-static-debug/CMakeCache.txt
[driver] Removing C:\msys64\home\bensh\projects\rustSatelliteDish\out\build\x64-windows-static-debug\CMakeFiles
[proc] Executing command: "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.EXE" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDebug -DVCPKG_HOST_TRIPLET=x64-windows-static-debug -DVCPKG_TARGET_TRIPLET=x64-windows-static-debug -DCMAKE_TOOLCHAIN_FILE=C:/msys64/opt/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_INSTALL_PREFIX=C:/msys64/home/bensh/projects/rustSatelliteDish/out/install/x64-windows-static-debug -SC:/msys64/home/bensh/projects/rustSatelliteDish -BC:/msys64/home/bensh/projects/rustSatelliteDish/out/build/x64-windows-static-debug -G Ninja
[cmake] -- Running vcpkg install
[cmake] warning: Embedding `vcpkg-configuration` in a manifest file is an EXPERIMENTAL feature.
[cmake] Detecting compiler hash for triplet x64-windows-static-debug...
[cmake] The following packages will be built and installed:
[cmake]<EMAIL_ADDRESS>[cmake]   * vcpkg-cmake:x64-windows-static-debug@2023-05-04
[cmake]   * vcpkg-cmake-config:x64-windows-static-debug@2022-02-06#1
[cmake] Additional packages (*) will be modified to complete this operation.
[cmake] Restored 0 package(s) from C:\Users\bensh\AppData\Local\vcpkg\archives in 246 us. Use --debug to see more details.
[cmake] Installing 1/3<EMAIL_ADDRESS>[cmake] Building<EMAIL_ADDRESS>[cmake] -- [OVERLAY] Loading triplet configuration from: C:\msys64\home\bensh\projects\rustSatelliteDish\vcpkg-triplets\x64-windows-static-debug.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake-config_x64-windows-static-debug/share/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake-config_x64-windows-static-debug/share/vcpkg-cmake-config/vcpkg-port-config.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake-config_x64-windows-static-debug/share/vcpkg-cmake-config/copyright
[cmake] -- Performing post-build validation
[cmake] Stored binaries in 1 destinations in 152 ms.
[cmake] Elapsed time to handle vcpkg-cmake-config:x64-windows-static-debug: 236 ms
[cmake] vcpkg-cmake-config:x64-windows-static-debug package ABI: 98f55d953f0b32a7f45227ca04e218a82aef90b235922e0bab513e210b80a5f4
[cmake] Installing 2/3<EMAIL_ADDRESS>[cmake] Building<EMAIL_ADDRESS>[cmake] -- [OVERLAY] Loading triplet configuration from: C:\msys64\home\bensh\projects\rustSatelliteDish\vcpkg-triplets\x64-windows-static-debug.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-windows-static-debug/share/vcpkg-cmake/vcpkg_cmake_configure.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-windows-static-debug/share/vcpkg-cmake/vcpkg_cmake_build.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-windows-static-debug/share/vcpkg-cmake/vcpkg_cmake_install.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-windows-static-debug/share/vcpkg-cmake/vcpkg-port-config.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-windows-static-debug/share/vcpkg-cmake/copyright
[cmake] -- Performing post-build validation
[cmake] Stored binaries in 1 destinations in 68 ms.
[cmake] Elapsed time to handle vcpkg-cmake:x64-windows-static-debug: 166 ms
[cmake] vcpkg-cmake:x64-windows-static-debug package ABI: 4cc59534cbcf56b4e0ada48bbee9a3d2ef1ec3b86560d470f6a83acaa6c147b9
[cmake] Installing 3/3<EMAIL_ADDRESS>[cmake] Building<EMAIL_ADDRESS>[cmake] -- [OVERLAY] Loading triplet configuration from: C:\msys64\home\bensh\projects\rustSatelliteDish\vcpkg-triplets\x64-windows-static-debug.cmake
[cmake] CMake Warning at ports/date/portfile.cmake:2 (message):
[cmake]   You will need to also install
[cmake]   https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplemental/windowsZones.xml
[cmake]   into your install location.
[cmake]
[cmake]   See https://howardhinnant.github.io/date/tz.html
[cmake] Call Stack (most recent call first):
[cmake]   scripts/ports.cmake:170 (include)
[cmake]
[cmake]
[cmake] -- Downloading https://github.com/HowardHinnant/date/archive/v3.0.1.tar.gz -> HowardHinnant-date-v3.0.1.tar.gz...
[cmake] -- Extracting source C:/msys64/opt/vcpkg/downloads/HowardHinnant-date-v3.0.1.tar.gz
[cmake] -- Applying patch 0001-fix-uwp.patch
[cmake] -- Applying patch 0002-fix-cmake-install.patch
[cmake] -- Applying patch fix-uninitialized-values.patch
[cmake] -- Using source at C:/msys64/opt/vcpkg/buildtrees/date/src/v3.0.1-4ba9ebd0db.clean
[cmake] -- Found external ninja('1.11.0').
[cmake] -- Configuring x64-windows-static-debug
[cmake] -- Building x64-windows-static-debug-dbg
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/date_x64-windows-static-debug/share/date/copyright
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/date_x64-windows-static-debug/share/date/usage
[cmake] -- Performing post-build validation
[cmake] warning: The folder /include is empty or not present. This indicates the library was not correctly installed.
[cmake] error: Found 1 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile: C:\msys64\opt\vcpkg\ports\date\portfile.cmake
[cmake] Stored binaries in 1 destinations in 431 ms.
[cmake] Elapsed time to handle date:x64-windows-static-debug: 7.4 s
[cmake] date:x64-windows-static-debug package ABI: 2415a217a5d358e1c1b4733396a4d1b79d270254e4442c59ef4f15d64a0369c8
[cmake] Total install time: 7.8 s
[cmake] date provides CMake targets:
[cmake]
[cmake]     find_package(date CONFIG REQUIRED)
[cmake]     target_link_libraries(main PRIVATE date::date date::date-tz)
[cmake]
[cmake] -- Running vcpkg install - done
[cmake] -- The CXX compiler identification is MSVC 19.39.33519.0
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.39.33519/bin/Hostx64/x64/cl.exe - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] RSD: Configuring for static linking
[cmake] CMake Error at C:/msys64/opt/vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package):
[cmake]   Could not find a package configuration file provided by "date" with any of
[cmake]   the following names:
[cmake]
[cmake]     dateConfig.cmake
[cmake]     date-config.cmake
[cmake]
[cmake]   Add the installation prefix of "date" to CMAKE_PREFIX_PATH or set
[cmake]   "date_DIR" to a directory containing one of the above files.  If "date"
[cmake]   provides a separate development package or SDK, be sure it has been
[cmake]   installed.
[cmake] Call Stack (most recent call first):
[cmake]   CMakeLists.txt:46 (find_package)
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
[proc] The command: "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.EXE" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDebug -DVCPKG_HOST_TRIPLET=x64-windows-static-debug -DVCPKG_TARGET_TRIPLET=x64-windows-static-debug -DCMAKE_TOOLCHAIN_FILE=C:/msys64/opt/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_INSTALL_PREFIX=C:/msys64/home/bensh/projects/rustSatelliteDish/out/install/x64-windows-static-debug -SC:/msys64/home/bensh/projects/rustSatelliteDish -BC:/msys64/home/bensh/projects/rustSatelliteDish/out/build/x64-windows-static-debug -G Ninja exited with code: 1

MinGW 64 GCC 13.2.0:
[main] Configuring project: rustSatelliteDish
[proc] Executing command: C:\msys64\mingw64\bin\cmake.EXE -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDebug -DVCPKG_HOST_TRIPLET=x64-mingw-static-debug -DVCPKG_TARGET_TRIPLET=x64-mingw-static-debug -DCMAKE_TOOLCHAIN_FILE=C:/msys64/opt/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_INSTALL_PREFIX=C:/msys64/home/bensh/projects/rustSatelliteDish/out/install/x64-mingw-static-debug -SC:/msys64/home/bensh/projects/rustSatelliteDish -BC:/msys64/home/bensh/projects/rustSatelliteDish/out/build/x64-mingw-static-debug -G Ninja
[cmake] -- Running vcpkg install
[cmake] warning: Embedding `vcpkg-configuration` in a manifest file is an EXPERIMENTAL feature.
[cmake] Detecting compiler hash for triplet x64-mingw-static-debug...
[cmake] A suitable version of powershell-core was not found (required v7.2.16) Downloading portable powershell-core 7.2.16...
[cmake] Downloading powershell-core...
[cmake] https://github.com/PowerShell/PowerShell/releases/download/v7.2.16/PowerShell-7.2.16-win-x64.zip->C:\msys64\opt\vcpkg\downloads\PowerShell-7.2.16-win-x64.zip
[cmake] Downloading https://github.com/PowerShell/PowerShell/releases/download/v7.2.16/PowerShell-7.2.16-win-x64.zip
[cmake] Extracting powershell-core...
[cmake] The following packages will be built and installed:
[cmake]<EMAIL_ADDRESS>[cmake]   * vcpkg-cmake:x64-mingw-static-debug@2023-05-04
[cmake]   * vcpkg-cmake-config:x64-mingw-static-debug@2022-02-06#1
[cmake] Additional packages (*) will be modified to complete this operation.
[cmake] A suitable version of 7zip was not found (required v23.1.0) Downloading portable 7zip 23.1.0...
[cmake] Downloading 7zip...
[cmake] https://github.com/ip7z/7zip/releases/download/23.01/7z2301-extra.7z->C:\msys64\opt\vcpkg\downloads\7z2301-extra.7z
[cmake] Downloading https://github.com/ip7z/7zip/releases/download/23.01/7z2301-extra.7z
[cmake] Extracting 7zip...
[cmake] Restored 0 package(s) from C:\Users\bensh\AppData\Local\vcpkg\archives in 103 us. Use --debug to see more details.
[cmake] Installing 1/3<EMAIL_ADDRESS>[cmake] Building<EMAIL_ADDRESS>[cmake] -- [OVERLAY] Loading triplet configuration from: C:\msys64\home\bensh\projects\rustSatelliteDish\vcpkg-triplets\x64-mingw-static-debug.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake-config_x64-mingw-static-debug/share/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake-config_x64-mingw-static-debug/share/vcpkg-cmake-config/vcpkg-port-config.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake-config_x64-mingw-static-debug/share/vcpkg-cmake-config/copyright
[cmake] -- Performing post-build validation
[cmake] Stored binaries in 1 destinations in 108 ms.
[cmake] Elapsed time to handle vcpkg-cmake-config:x64-mingw-static-debug: 194 ms
[cmake] vcpkg-cmake-config:x64-mingw-static-debug package ABI: 2c60572705deb0bac78bc04a58b3d924f3259e1167af454aff25588a335d9e3a
[cmake] Installing 2/3<EMAIL_ADDRESS>[cmake] Building<EMAIL_ADDRESS>[cmake] -- [OVERLAY] Loading triplet configuration from: C:\msys64\home\bensh\projects\rustSatelliteDish\vcpkg-triplets\x64-mingw-static-debug.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-mingw-static-debug/share/vcpkg-cmake/vcpkg_cmake_configure.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-mingw-static-debug/share/vcpkg-cmake/vcpkg_cmake_build.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-mingw-static-debug/share/vcpkg-cmake/vcpkg_cmake_install.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-mingw-static-debug/share/vcpkg-cmake/vcpkg-port-config.cmake
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/vcpkg-cmake_x64-mingw-static-debug/share/vcpkg-cmake/copyright
[cmake] -- Performing post-build validation
[cmake] Stored binaries in 1 destinations in 63.3 ms.
[cmake] Elapsed time to handle vcpkg-cmake:x64-mingw-static-debug: 159 ms
[cmake] vcpkg-cmake:x64-mingw-static-debug package ABI: ae36838f97101011078356bbd82f5f5930fb48e7366dd15fe43f30b3ad03e000
[cmake] Installing 3/3<EMAIL_ADDRESS>[cmake] Building<EMAIL_ADDRESS>[cmake] -- [OVERLAY] Loading triplet configuration from: C:\msys64\home\bensh\projects\rustSatelliteDish\vcpkg-triplets\x64-mingw-static-debug.cmake
[cmake] CMake Warning at ports/date/portfile.cmake:2 (message):
[cmake]   You will need to also install
[cmake]   https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplemental/windowsZones.xml
[cmake]   into your install location.
[cmake]
[cmake]   See https://howardhinnant.github.io/date/tz.html
[cmake] Call Stack (most recent call first):
[cmake]   scripts/ports.cmake:170 (include)
[cmake]
[cmake]
[cmake] -- Downloading https://github.com/HowardHinnant/date/archive/v3.0.1.tar.gz -> HowardHinnant-date-v3.0.1.tar.gz...
[cmake] -- Extracting source C:/msys64/opt/vcpkg/downloads/HowardHinnant-date-v3.0.1.tar.gz
[cmake] -- Applying patch 0001-fix-uwp.patch
[cmake] -- Applying patch 0002-fix-cmake-install.patch
[cmake] -- Applying patch fix-uninitialized-values.patch
[cmake] -- Using source at C:/msys64/opt/vcpkg/buildtrees/date/src/v3.0.1-4ba9ebd0db.clean
[cmake] -- Found external ninja('1.11.1').
[cmake] -- Configuring x64-mingw-static-debug
[cmake] -- Building x64-mingw-static-debug-dbg
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/date_x64-mingw-static-debug/share/date/copyright
[cmake] -- Installing: C:/msys64/opt/vcpkg/packages/date_x64-mingw-static-debug/share/date/usage
[cmake] -- Performing post-build validation
[cmake] warning: The folder /include is empty or not present. This indicates the library was not correctly installed.
[cmake] error: Found 1 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile: C:\msys64\opt\vcpkg\ports\date\portfile.cmake
[cmake] Stored binaries in 1 destinations in 347 ms.
[cmake] Elapsed time to handle date:x64-mingw-static-debug: 10 s
[cmake] date:x64-mingw-static-debug package ABI: aa6c6e72ebf92e93debbaecc26aacf852372449d76f5a1f5fdce835beaf170a9
[cmake] Total install time: 10 s
[cmake] date provides CMake targets:
[cmake]
[cmake]     find_package(date CONFIG REQUIRED)
[cmake]     target_link_libraries(main PRIVATE date::date date::date-tz)
[cmake]
[cmake] -- Running vcpkg install - done
[cmake] -- The CXX compiler identification is GNU 13.2.0
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: C:/msys64/mingw64/bin/c++.exe - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] RSD: Configuring for static linking
[cmake] CMake Error at C:/msys64/opt/vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package):
[cmake]   Could not find a package configuration file provided by "date" with any of
[cmake]   the following names:
[cmake]
[cmake]     dateConfig.cmake
[cmake]     date-config.cmake
[cmake]
[cmake]   Add the installation prefix of "date" to CMAKE_PREFIX_PATH or set
[cmake]   "date_DIR" to a directory containing one of the above files.  If "date"
[cmake]   provides a separate development package or SDK, be sure it has been
[cmake]   installed.
[cmake] Call Stack (most recent call first):
[cmake]   CMakeLists.txt:46 (find_package)
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
[proc] The command: C:\msys64\mingw64\bin\cmake.EXE -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDebug -DVCPKG_HOST_TRIPLET=x64-mingw-static-debug -DVCPKG_TARGET_TRIPLET=x64-mingw-static-debug -DCMAKE_TOOLCHAIN_FILE=C:/msys64/opt/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_INSTALL_PREFIX=C:/msys64/home/bensh/projects/rustSatelliteDish/out/install/x64-mingw-static-debug -SC:/msys64/home/bensh/projects/rustSatelliteDish -BC:/msys64/home/bensh/projects/rustSatelliteDish/out/build/x64-mingw-static-debug -G Ninja exited with code: 1

Additional context
Tried running with a clean state:

wiped CMake output folder tree in project
ran git clean -fxd in vcpkg install
deleted vcpkg folder tree from %LOCALAPPDATA%
pulled latest vcpkg master
ran /bootstrap-vcpkg.sh -disableMetrics

Some info on the state of vcpkg:
$ find . -iname '*date*.cmake'
./buildtrees/date/src/v3.0.1-4ba9ebd0db.clean/cmake/dateConfig.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/Export/a52b05f964b070ee926bcad51d3288af/dateTargets-debug.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/Export/a52b05f964b070ee926bcad51d3288af/dateTargets.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/dateConfigVersion.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/dateTargets.cmake
./packages/date_x64-mingw-static-debug/share/date/dateTargets-debug.cmake

$ find ./buildtrees/date/x64-mingw-static-debug-dbg
./buildtrees/date/x64-mingw-static-debug-dbg
./buildtrees/date/x64-mingw-static-debug-dbg/.ninja_deps
./buildtrees/date/x64-mingw-static-debug-dbg/.ninja_log
./buildtrees/date/x64-mingw-static-debug-dbg/build.ninja
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeCache.txt
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CMakeCCompiler.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CMakeCXXCompiler.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CMakeDetermineCompilerABI_C.bin
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CMakeDetermineCompilerABI_CXX.bin
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CMakeRCCompiler.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CMakeSystem.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdC
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdC/a.exe
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdC/CMakeCCompilerId.c
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdC/tmp
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdCXX
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdCXX/a.exe
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdCXX/CMakeCXXCompilerId.cpp
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/3.28.3/CompilerIdCXX/tmp
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/cmake.check_cache
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/CMakeConfigureLog.yaml
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/CMakeScratch
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/date-tz.dir
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/date-tz.dir/src
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/date-tz.dir/src/tz.cpp.obj
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/Export
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/Export/a52b05f964b070ee926bcad51d3288af
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/Export/a52b05f964b070ee926bcad51d3288af/dateTargets-debug.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/Export/a52b05f964b070ee926bcad51d3288af/dateTargets.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/pkgRedirects
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/rules.ninja
./buildtrees/date/x64-mingw-static-debug-dbg/CMakeFiles/TargetDirectories.txt
./buildtrees/date/x64-mingw-static-debug-dbg/cmake_install.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/dateConfigVersion.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/dateTargets.cmake
./buildtrees/date/x64-mingw-static-debug-dbg/install_manifest.txt
./buildtrees/date/x64-mingw-static-debug-dbg/libdate-tz.a

$ find ./packages/date_x64-mingw-static-debug/share/date
./packages/date_x64-mingw-static-debug/share/date
./packages/date_x64-mingw-static-debug/share/date/copyright
./packages/date_x64-mingw-static-debug/share/date/dateTargets-debug.cmake
./packages/date_x64-mingw-static-debug/share/date/usage
./packages/date_x64-mingw-static-debug/share/date/vcpkg.spdx.json
./packages/date_x64-mingw-static-debug/share/date/vcpkg_abi_info.txt

This appears to be some sort of problem with custom triplets. This wasn't a problem with my other project that doesn't use date, though, so I have to believe there's a problem with the date package here.

Based on advice from #33456, I trashed my custom/overlay triplets and used CMake build presets to sort out debug versus release. It mostly works, except for some warts that are out of scope of this issue.
If the VCPKG_BUILD_TYPE stuff is really the cause here, then this can be closed. On the other hand, I thin it's an actual issue if date is failing to build simply due to use of a custom triplet that overlays a built-in one.

There is no general problem with overlay triplets. Having set(VCPKG_BUILD_TYPE debug) in the triplet file is known to be broken.

There is no general problem with overlay triplets. Having set(VCPKG_BUILD_TYPE debug) in the triplet file is known to be broken.

Do you know if there's an open issue besides #33456 that captures this known breakage? If so, I'd like to cross-reference it with this and then close it, in case anyone needs another way to reproduce a problem resulting from it.


Cafe Beverage Center

Hi - I was wondering what it would take to extend support for the Cafe Beverage Fridge.  It show's up in my setup now (bar fridge), but the only option is Sabbath Mode.  I would like to see if the following could be included (based on the app):

Door Status (open/closed)
Lighting - Intensity (0-100%)
Lighting - Display Mode (on/off)
Lockout Mode (on/off)
Temperature

Happy to provide anything you may need.  As you can see, I have 9 GE Appliances (Espresso maker not shown)
Cafe:

Refrigerator
Beverage Center
Microwave
Dish Washer
Espresso Maker

Profile:

Opal Ice Maker 2.0

Standard:

Oven
Washer
Dryer

I have the same device.  Here's what the developer needs to build out the functionality. I have the same request and here's the response.
"This can be done, but you'll need to get the raw debug log from the underlying API package (simbaja/gehome). Basically, you'll need to clone that, and then run the websocket_example for a minute to let it pull all the information that we'll need to get the sensors here. At that point, we can work through interpreting the data, then can add to the integration."

Ok, I made an easier way to get to the data. Install gehomesdk (pip install gehomesdk) then run gehome-appliance-data. It'll ask for your credentials, but should display the details I need.

@ichrispod, I've added the functionality to the latest dev branch (0.6.5-dev1), give it a shot, but based on @kksligh's feedback, looks like we're good here.

I deleted the integration and pulled from the 0.6.5-dev1 branch (opens HACS, clicked on your tile, clicked re-download, choose the 0.6.5-dev1 version.  restarted HASS, re added the integration and it's still only showing Sabbath Mode as an available control.

Maybe it's a different model from @kksligh's version?  Can you run that application and post the log?


Demos Xcode 11.3.1 support

Makes sense to give as many folks an opportunity to run the examples as possible.

11.3 test runs fails occasionally due to what appears to be a bug in SPM (package targets should not depend on each other internally, like ComposableArchitectureTestSupport).
We could merely build the projects on 11.3 (and not run tests) to avoid failing the build, but it looks like moving ComposableArchitectureTestSupport to its own package/repo might be the better workaround, especially if #57 is a related problem.
Having 2 repos isn't an ideal user experience, but it may be out of our hands till SPM can support this use case itself.


Subscription durability

We handle subscriptions drops, but it would be nice to have a story around failures in event handlers.
When handling an event in a subscription fails, the following possible scenarios apply:

Reason
Remedy

Transient failure
Retry individual handlers

Permanent failure (poison)
Log and continue  Full stop, make unhealthy

Checkpoint storage failure
Endless retry, make unhealthy

We could support all the scenarios. The question is only how to configure it, and what is the good default.

For some subscription types, we have even more options.
RMQ subscription can:

Ack
Nack and drop
Nack and requeue

ESDB persistent subscriptions can:

Ack
Nack
Park

How the subscription could know what to do with the message?

Google PubSub - Ack and Nack.

Maybe Polly can be used here? The API is pretty flexible and seems to be the .NET goto for advanced error handling, reties etc. Not too familiar with this library yet (on my todo list), but a builder pattern of some sort might be good here?
services.AddEventHandler<SomeHandler>()
    .WithPolicy(...);

MS docs on HttpClient integration with Polly: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/implement-http-call-retries-exponential-backoff-polly

Log and continue. Full stop, make unhealthy

This would indicate that the policy in this case should be able to return a signal/enum value or something to indicate what the service should do about the handler? Not sure how "plug and play" Polly would be for that scenario

@martinothamar Polly can help with retries and circuit breakers. However, as I mentioned, some transports have their own retry capability. And RMQ in particular has a way to re-queue the message, which is very helpful when handling "it's not there yet" situations (quite common).
If we should have middlewares in subscriptions, I haven't decided yet. #28 brings some foundation to the future improvements of subscriptions.
One principle of Eventuous is not to ignore the transport, provide as little as possible abstraction on top of it, and use the transport native capabilities.
Adding policies to handlers is something I also thought of, looking at HttpClient Polly extensions. The issue there is the scope, as if you look at the code of those extensions, you'll see that it's not really a good fit for event handlers.

@martinothamar btw I just realised that I completely agree with what you wrote. I also hardly see a plug-and-play scenario for Polly here.
The current consumer implementation allows, in theory, to implement a retrying consumer. However, as you rightfully mentioned, how does the consumer know to which handler the policy applies and what to do if only one of the handlers fails?
I can now think of the following:

Extend AddEventHandler with some sort of subscription handler builder
Such a builder can allow wrapping the handler in a retry handler
Add a E-s.Subscriptions.Polly package, which would contain a Polly-driven retry handler


v2  seems not support AsyncClient.

When calling
await submit_metrics  with v2 api,
the error is
IntakePayloadAccepted has no attribute '0' at ['['received_data']

Hi,
Can you share the version used and the code? It's probably unrelated to async support. The following example works fine for me:
from datetime import datetime
from datadog_api_client import AsyncApiClient, Configuration
from datadog_api_client.v2.api.metrics_api import MetricsApi
from datadog_api_client.v2.model.metric_intake_type import MetricIntakeType
from datadog_api_client.v2.model.metric_payload import MetricPayload
from datadog_api_client.v2.model.metric_point import MetricPoint
from datadog_api_client.v2.model.metric_resource import MetricResource
from datadog_api_client.v2.model.metric_series import MetricSeries

body = MetricPayload(
    series=[
        MetricSeries(
            metric="system.load.1",
            type=MetricIntakeType(0),
            points=[
                MetricPoint(
                    timestamp=int(datetime.now().timestamp()),
                    value=0.7,
                ),
            ],
            resources=[
                MetricResource(
                    name="dummyhost",
                    type="host",
                ),
            ],
        ),
    ],
)

async def main():
    configuration = Configuration()
    async with AsyncApiClient(configuration) as api_client:
        api_instance = MetricsApi(api_client)
        response = await api_instance.submit_metrics(body=body)

        print(response)

import asyncio
asyncio.run(main())

@therve Yes, you are right, my bad. It is just the v1 and v2 do not have the same response format of submit_metrics function, and I was still refering to v1 example to write the response. Maybe it is better to also update v2 example. But anyway, thank you and I will close this issue.


Custom resource rewrite

This is the pull request for #151. It's nowhere near ready yet. :)

Resources

[x] frontend
[x] backend
[x] global_config
[x] default_config
[x] package install
[x] source install

@teknofire and the others I've tagged for review. It'd be great to hear some feedback on the direction we're heading with this rewrite, and to see if it meets your needs, at least in some generic way.
Thanks!

Closes #151, #111,
Closes #159 ACLs are a Hash/Array inside a backends & frontends
Closes #148 we no longer use Chef Search.
Possibly cleans up #58 as we have a clean way of defining backends.


Update community files (#3910)

Signed-off-by: Knative Automation<EMAIL_ADDRESS>

OCF Webhook is merging this PR


Write page Install SuperOffice Server install

@pavlas77 Is this the same as this documentation? Or is this still another file that must be created?

Already done


Update required build and runtime variables

This updates variable descriptions in the readme and the dockerfile

Thank you for your contribution 🙏


OrderedList does not respect "type" attribute

OrderedList appears to be setting list-style to none (via .drac-list), which causes the type attribute to not work.
e.g. why applying type="a" (for lowercase letters), the list still renders numbers.

From what I understand after a quick scan of the OrderedList styles, Dracula UI implements its own list styles for the OrderedList component, hence why there's a list-style: none on .drac-list. The list numbers are then basically re-implemented via a CSS counter(). Fortunately, I think we can get other numbering types by passing in another parameter to that counter() function!
The additional parameter for counter() is the same as a list-style-type property, which we can use in our OrderedList to get the same effect as the <ol>'s type attribute.
In the spirit of Hacktoberfest, I took my shot at trying to solve this issue! I think we can modify src/styles/list.css to accept a CSS variable as a second argument to the counter() function:
.list-ordered li::before {
  content: counter(li, var(--type, decimal))'.';
  /* the rest of the styles remain the same... */
}

Then we can create additional classes to set that --type variable. For example:
.list-ordered-lower-alpha {
  --type: lower-alpha;
}

.list-ordered-upper-alpha {
  --type: upper-alpha;
}

And then for the React component, we can also accept a type prop and then set one of the additional classes accordingly:
const orderedListTypes = {
  1: 'drac-list-ordered-decimal',
  a: 'drac-list-ordered-lower-alpha',
  A: 'drac-list-ordered-lower-alpha',
  i: 'drac-list-ordered-lower-roman',
  I: 'drac-list-ordered-lower-roman'
}

This is a temporary fix until we are able to have case-sensitive attribute selectors. Ideally we should be able to set the --type variable depending on the type attribute of the OrderedList component:
.list-ordered[type="a" s] {
  --type: lower-alpha;
}

.list-ordered[type="A" s] {
  --type: upper-alpha;
}

But that method only works on Firefox as of now, and for other browsers the type attribute selector is always case insensitive, resulting the styles for .list-ordered[type="a"] conflicting with .list-ordered[type="A"].


[QUESTION] Need specifications about field of indecies Skywalking created in Elasticsearch.

Why do you submit this issue?
[ ] Question or discussion

Question

A specification about the field of indecies that skywalking creates in elasticsearch, telling the relationship of those indecies and what the field represent for, cuz reading from source code may help but is of low efficiency.

Why do I submit?
I've read official docs and various info on the internet for several days for these informations but got nearly nothing useful nor strongly related to my expectation.
Really need help. Thanks!

We don't that kind of doc. Sorry. Different storage implementations have different designs in different versions.
And from a community, no one contributed this kind of doc.

Finally I managed to find that what I want is just there called data-query-protocol, but thanks for your reply anyway. :)


fix: update absl to std to avoid building failture

Signed-off-by: wbpcode<EMAIL_ADDRESS>The return value type of ParseCpulist has been updated from absl::optional<...> to std::optional<...> after https://github.com/google/tcmalloc/commit/b2c523cd328526bd867207f43de06d5b9e56fc03.
But we still try to assign the return value to a variable of type absl::optional<...>. If the ABSL_OPTION_USE_STD_OPTIONAL is set to zero, then the building will fail.

cc @ckennelly


Address JOSS reviewer comments

This issue is for addressing the JOSS reviewer comments:

https://github.com/openjournals/joss-reviews/issues/3414#issuecomment-877210440
https://github.com/openjournals/joss-reviews/issues/3414#issuecomment-879660026

All reviewers' comments have been addressed. The paper has been published at https://doi.org/10.21105/joss.03414


add flags for enabling optional persistent path from shortcuts

Using the persistent path written to disk is now optional, but we want to enable that feature for users running the webview application from a shortcut that was added during installation of the conda-packed distribution.

requires bumps >= 1.0.0a6 but that requirement has already been changed in pyproject.toml


Make it easier for quorum-genesis-tool to be used as a library

The existing module entry point to the this package parses command line args and eventually calls generateNetworkConfig() but it never re-exports the generateNetworkConfig function, publishes type declarations, or exports types from the root module
This PR adds all of that so that quorum-genesis-tool can also be called as a library by another JS script
Worth nothing that this PR isn't actually required to accomplish using this as a library (you could do a nested import), but it's nice to have type safety and import from the official package entry point
Completed quality check list

[x] npm ci (node 16)
[x] npm run lint
[x] npm run build
[x] npm pack and install locally for manual verification
[x] npm run test
[x] Make sure CI and CodeQL pipelines pass with no issues

Hi @joshuafernandes and @Ezzahhh
I see you are both listed as contributors in package.json
Could you please review this PR for me when you are able and let me know if this would be an acceptable change to merge in?
Thanks,
Luis

Hi @luisnaranjo733, thanks for the contribution, this looks good to me and will be merged and released

Thank you!


Logstash could not write udp connection refused

Problem description
When I try to run
docker-compose -f docker-compose.yml -f extensions/logspout/logspout-compose.yml up
I get the error (Or is it an error?)
2018/06/08 07:49:43 logstash: could not write:write udp <IP_ADDRESS>:55829-><IP_ADDRESS>:5000: write: connection refused
Sorry if this already solved but I'm on this problem for days but couldn't find anything to solve it. I hope it has some silly answer I couldn't see. Thanks in advance.
Extra information

Stack configuration
Is the same.
Docker setup
Docker version 18.03.1-ce, build 9ee9f40

docker-compose version 1.21.2, build a133471
docker-py version: 3.3.0
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

Docker logs
logspout_1       | #   ADAPTER	ADDRESS		CONTAINERS	SOURCES	OPTIONS
logspout_1       | #   logstash	logstash:5000				map[]
logspout_1       | 2018/06/08 07:45:07 logstash: could not write:write udp <IP_ADDRESS>:56225-><IP_ADDRESS>:5000: write: connection refused
logspout_1       | # logspout v3.2.5-custom by gliderlabs
logspout_1       | # adapters: logstash raw udp tcp
logspout_1       | # options : persist:/mnt/routes
logspout_1       | # jobs    : pump routes http[]:80
logspout_1       | # routes  :

Thanks for reporting this @sodaliAyran. It looks indeed like logspout is using UDP instead of TCP now. I'll look into what needs to be reconfigured.

Use by setting a docker environment variable ROUTE_URIS=logstash://host:port to the Logstash server. The default protocol is UDP, but it is possible to change to TCP by adding +tcp after the logstash protocol when starting your container.

For example:
ROUTE_URIS=logstash+tcp://logstash.home.local:5000

@sodaliAyran you did not follow all the the instructions on https://github.com/deviantony/docker-elk/tree/master/extensions/logspout.
It is mentioned a UDP input is required inside the Logstash pipeline.
Closing.

I used logspout:v2 image to fix the problem. But it was working fine with v3 image till yesterday.I have included a snippet from my docker compose file.
logspout:
image: gliderlabs/logspout:v2
command: 'udp://logstash:5044'
links:
- logstash
volumes:
- '/var/run/docker.sock:/tmp/docker.sock'
depends_on:
- odfe-node2
- logstash
- kibana
networks:
- odfe-net
This is my logstash.conf
input {
tcp {
port => 5000
}
udp{
port => 5044
codec => json
type => dockerlog
   }

}
output {
elasticsearch {
hosts => "odfe-node2:9200"
}
}
This is my repo, tested and working fine for me.
https://github.com/sharonsahadevan/opendistro-elk-logspout/

@sodaliAyran you did not follow all the the instructions at https://github.com/deviantony/docker-elk/tree/master/extensions/logspout.
It is mentioned a UDP input is required inside the Logstash pipeline.
Closing.

2 years on and still facing this issue. Yet you decided the reason without reasoning back then.


Performance issues with LP

https://timings.aikar.co/v2/?id=8f017635ea9f4627ae4717a4c521d2b3&start=1481752687&end=1481752909&section=lag
[-]luckperms::userGetPermissionValuecount(4) total(12.43% 2.456s, 7.32% of tick)  avg(613.88ms per - 3.66ms/0.01 per tick)
[-]luckperms::userGetPermissionValuecount(54) total(4.25% 0.84s, 2.50% of tick)  avg(15.55ms per - 1.25ms/0.08 per tick)
[-]luckperms::groupGetParentscount(2818) total(30.48% 3.451s, 164.34% of tick)  avg(1.22ms per - 82.17ms/67.10 per tick)
Any idea what is causing these slowdowns?

Those were caused by an accidental loop in the inheriting process. This only affected the Sponge Environment with LuckPerms 2.16.25. The Bukkit environment was unaffected.
While inherit loops are the users fault I see another issue at hand:
Group Manager
inherits: admin
inherits: perms_admin
Group Admin:
inherits: jradmin
inherits: perms_admin
Group Jr Admin
inherits: perms_admin
If the list goes on, this creates quite some unnecessary overhead.

Duplicate of #69


Snippets for handling control add-ins

I started porting our control add-ins to AL and noticed that there is no snippets to help adding control add-ins, so I created 2 snippets taddin (which adds controladdin object) and tusercontrol (which adds add-in control to page).

Thank you for your contribution @niku-live, I added a few comments on the snippets you added :)

Thank you for your suggestions, I fixed consistency problems (at least I hope :) ).


More config options / Compat with Betweenlands

Heya,
was wondering if it's possible to get a couple more config options to make the mod more compatible with the betweenlands.
One thing is the underwater fog - in the betweenlands it's really foggy when you go into water (bypassed with armor you craft later), but using Aqua Acrobatics removes that fog. An option to not remove the fog would be awesome if possible.

The other thing has to do with getting pushed out of blocks - there is a ring of dispersion that lets the player temporarily walk through blocks while holding shift. With Aqua Acrobatics you get pushed out of those blocks and can't really fully walk through them. I've tried this on all the available settings.
Would it be possible to get a config option to disable that behaviour entirely, or perhaps disable it when the player is sneaking?
Cheers!
SC

I've fixed the fog issue locally (any dimension using WorldProviderBetweenlands won't have the fog changed); working on a fix for the dispersion ring next.
On another note, did you override the water and fog colors manually using the config? It looks great in your picture compared to what it looks for me. If you let me know what values you used I can add them upstream so it doesn't just use the 1.13 blue color.

I can't seem to reproduce the ring issue locally. Could you please send a video/screenshot showing a block layout that reproduces this?
The only issue I see is that the lower sneak height in Aqua Acrobatics seems to cause the overlay to appear even if the player's head isn't inside a block, however, I think this would need to be fixed on the Betweenlands end (could the height check be relaxed slightly?).

Hey,
here is a list of the biome water colors
            thebetweenlands:swamplands,1589792,1589792
            thebetweenlands:swamplands_clearing,1589792,1589792
            thebetweenlands:thebetweenlands:coarse_islands,1784132,1784132
            thebetweenlands:deep_waters,1784132,1784132
            thebetweenlands:marsh_0,4742680,4742680
            thebetweenlands:marsh_1,4742680,4742680
            thebetweenlands:patchy_islands,1589792,1589792
            thebetweenlands:raised_isles,1784132,1784132
            thebetweenlands:sludge_plains,3813131,3813131
            thebetweenlands:sludge_plains_clearing,3813131,3813131

and yeah i'll double check the ring and see if i can male a video of it!
Thanks for doing the fix and using the default colors, appreciate it! :D
-SC

Okay here is one video (i have another one where i try to walk through 2+ tall blocks but it's a bit more difficult to see whats going on there)
https://www.youtube.com/watch?v=jU1Zhj8Ti0g
Basically all im doing is holding shift and moving forward. Seems like once i reach the point where i would move into another block i get pushed to the side. It doesn't always happen, sometimes it's fine.

It's very tricky to reproduce, but I think I managed to track down the corner case. This should be fixed in 1.9.0, but unfortunately it was hard to confirm. Let me know if it still happens with that version. :slightly_smiling_face:

Awesome will check it out once it's up, thanks a bunch!

It's up already; CurseForge approves my stuff a lot faster than it used to.

Thats fast indeed! Just checked and unfortunately still happening. I don't think it's necessarily the ring thinking you are no longer sneaking or something (otherwise you would end up where you started, instead of getting pushed out of it). Bit of an edge case of course but i think the code that checks if the player is inside a block and pushes them out of it would have to check if the ring is active?  But yeah not the end of the world if it won't work heh.
Water color/fog works great now!

i think the code that checks if the player is inside a block and pushes them out of it would have to check if the ring is active?

It does that already. Forge has an event for disabling pushing out of blocks which Aqua Acrobatics respects, and the ring does use. I think the underlying issue is related to the fact that Aqua Acrobatics does some.... magic with the sneak state and reports the player to not be sneaking depending on whether the collision box has a block inside it. When the ring gets told the player is no longer sneaking, it will allow them to suddenly be pushed out of the block mid-phase.
I'm having difficulty reproducing it after my fix so maybe it's faster for you to test (if you don't mind). Can you give this build a try? Don't use this on a world you care about, it reports the player as always sneaking to the ring, which will cause you to be able to phase through everything. I'd like to see if you still get pushed out of blocks in this case or not.
aqua.zip
Also, are you testing in singleplayer or multiplayer? (I just want to rule out desyncs as a possible cause.)

Just tried the build (sorry for the delay!) and so far its looking good! Haven't been getting pushed out of a block yet when i wasn't suppose to.
Im in single player and testing in a small instance with pretty much just those two mods.
There is another small thing i found - normally when you go into tar it's really difficult to move around in (and get back to the surface). It's much easier with Aqua Acrobatics. It's not too bad though!

Okay, so it is related to the sneaking. There's probably another check for it in the Betweenlands code that I need to patch.

Sounds like it, i'll double check too (im part of the BL dev team but just recently joined so not 100% familiar with all the code base yet :P)

How does this build work for you?
aqua2.zip

Looks good, can't recreate the issue with this build

Perfect. I'll get this published on CurseForge when I'm at my main PC.

Sweet, thanks a lot for working on this!

1.9.1 is published with the new fix.

About the tar: what part of the Betweenlands code marks tar as being difficult to move through? I ask because in my private modpack, I use Buildcraft with Aqua Acrobatics, and the Buildcraft oil is still just as difficult to move through as in vanilla, so I'm wondering what the difference is between the two implementations. It looks like they use Entity.setInWeb() to do it?

Should be this part https://github.com/Angry-Pixel/The-Betweenlands/blob/7e54e8f64dee155e649ddcf7512dce69af557ea7/src/main/java/thebetweenlands/common/block/terrain/BlockTar.java#L140
I think buildcraft might use a low liquid density?


@keyup and @keydown events in vue-text-mask

Hello, could you please add @keyup and @keydown events support for the vue component?
I would like to listen keys that doesn't produces value (like arrow keys) but :

The keypress event is fired when a key that produces a character value is pressed down.

https://developer.mozilla.org/en-US/docs/Web/Events/keypress

For anyone who finds this (and @SamuelRiversMoore) - @keypress is supported right now - I had to go look because I bumped my head on this too and this is poorly (not) documented.
Though ideally the Vue component should just pass down all unused attrs/events - I'll look at a PR for this soon.


Added new section - TAKE TWO

Hi Sudesh,
I couldn't figure out how to reopen the pull request to I have started a new one. Please merge. Thanks!

OK! thanks.


Copy sample.env to .env on generation

I know issue #668 said we should generate .env instead of .sample. but this would break the behavior of bin/setup. Since .env is ignored by git, all other collaborators wouldn't have a base env file to copy. Instead I added an extra step to copy .env into the generated suspenders project as well as .sample.env.

this would break the behavior of bin/setup. Since .env is ignored by git, all other collaborators wouldn't have a base env file to copy

We can remove that step, as well. Soon @geoffharcourt will merge https://github.com/thoughtbot/dotfiles/pull/442, which will make our dotfiles not ignore .env.
Thank you!

@tute Cool, thanks! I'll get that taken care of and pushed up.

@tute with .ctags located in templates/dotfiles/ I feel we should move templates/sample.env to templates/dotfiles/.env. What do you think?

@tute with .ctags located in templates/dotfiles/ I feel we should move templates/sample.env to templates/dotfiles/.env. What do you think? This will allow us to use the existing copy_dotfiles method, which looks to copy the entire templates/dotfiles directory.

Makes sense to me :+1:

Looks good! Can you please rebase so I merge? Thank you!

rebasing upstream/master is diverging master from origin/master. I can't pull from there because it can't fast-forward. Am I doing something wrong?

It was all right, it had merge conflicts. I solved them, and merged into master. Thank you!

Oh cool, thanks @tute!

:+1: thanks guys!


Use the same size drop down inputs in the navigation bar

At the moment the two drop-downs inputs have a slightly different height

That one has been triggering my OCD for quite a while already :D I'll make it happen!


Add sdk to 2.1 RC known-good

Waiting for https://github.com/dotnet/sdk/pull/2178 so that source-build can use the ProdCon branch.

Submitted https://github.com/dotnet/source-build/pull/478 to add this repo.

Done with https://github.com/dotnet/source-build/pull/478.


[Feature request] Node grouping

This feature serves 2 use cases:

Grouping nodes sharing similar characteristics: same category, steps in a phase,...
Making it possible to build ERD-like diagrams

My personal need is to build an ERD tool like the image below. I initially thought about using custom nodes, but it's hard to synchronize the position of foreign keys with their ports (handle ends). If we view tables as groups of nodes, it seems easier to implement.

Hi, if I understand your request correctly, a diagram like this should already be possible to build. Have you tried using multiple handles like in this example: https://reactflow.dev/examples/custom-node ?

@chrtze,
It's ok to do that, but I want to have 2 ends of the the handle precisely point to the FK field and PK field (like in the image above), not just point arbitraryly to the side of tables.
In the custom node example, we have to manually set top and bottom css. It's hard to determine where should we place handle ends.

For that, you have to place the Handles inside the table row and position it relative to it. Example: https://codesandbox.io/s/vigilant-montalcini-mwou6?file=/src/App.js


Data race on EVP_CIPHER

Hi.
I have some code that needs both a server and a client (TLS) in the same multi threaded process. TSAN reports a data race:
14:18:03  WARNING: ThreadSanitizer: data race (pid=17)
14:18:03    Write of size 4 at 0x7b3c000002d4 by main thread:
14:18:03      #0 evp_cipher_cache_constants openssl-prefix/src/openssl-build/../openssl/crypto/evp/evp_lib.c:298:28 (a.out+0x3673443)
14:18:03      #1 EVP_CIPHER_fetch openssl-prefix/src/openssl-build/../openssl/crypto/evp/evp_enc.c:1614:28 (a.out+0x366e747)
14:18:03      #2 ssl_evp_cipher_fetch openssl-prefix/src/openssl-build/../openssl/ssl/ssl_lib.c:5886:12 (a.out+0x35c33a4)
14:18:03      #3 ssl_load_ciphers openssl-prefix/src/openssl-build/../openssl/ssl/ssl_ciph.c:332:19 (a.out+0x35af9bd)
14:18:03      #4 SSL_CTX_new_with_libctx openssl-prefix/src/openssl-build/../openssl/ssl/ssl_lib.c:3167:10 (a.out+0x35bd5e8)
14:18:03      #5 SSL_CTX_new openssl-prefix/src/openssl-build/../openssl/ssl/ssl_lib.c:3307:12 (a.out+0x35bdbed)
14:18:03      #6 asio::ssl::context::context(asio::ssl::context_base::method) include/asio/ssl/impl/context.ipp:273:15 (a.out+0x356e08d)
14:18:03
14:18:03    Previous read of size 4 at 0x7b3c000002d4 by thread T12:
14:18:03      #0 EVP_CIPHER_block_size openssl-prefix/src/openssl-build/../openssl/crypto/evp/evp_lib.c:308:20 (a.out+0x3673515)
14:18:03      #1 EVP_CIPHER_CTX_block_size openssl-prefix/src/openssl-build/../openssl/crypto/evp/evp_lib.c:313:12 (a.out+0x3673515)
14:18:03      #2 EVP_EncryptUpdate openssl-prefix/src/openssl-build/../openssl/crypto/evp/evp_enc.c:712:17 (a.out+0x366f214)
14:18:03      #3 construct_stateless_ticket openssl-prefix/src/openssl-build/../openssl/ssl/statem/statem_srvr.c:3992:17 (a.out+0x360039a)
14:18:03      #4 tls_construct_new_session_ticket openssl-prefix/src/openssl-build/../openssl/ssl/statem/statem_srvr.c:4155:17 (a.out+0x360039a)
14:18:03      #5 write_state_machine openssl-prefix/src/openssl-build/../openssl/ssl/statem/statem.c:844:37 (a.out+0x35ebb45)
14:18:03      #6 state_machine openssl-prefix/src/openssl-build/../openssl/ssl/statem/statem.c:444:21 (a.out+0x35ebb45)
14:18:03      #7 ossl_statem_accept openssl-prefix/src/openssl-build/../openssl/ssl/statem/statem.c:256:12 (a.out+0x35ec99e)
14:18:03      #8 SSL_do_handshake openssl-prefix/src/openssl-build/../openssl/ssl/ssl_lib.c:3829:19 (a.out+0x35ba330)
14:18:03      #9 SSL_accept openssl-prefix/src/openssl-build/../openssl/ssl/ssl_lib.c:1715:12 (a.out+0x35ba141)

The first trace is from the TLS client when it is constructed. It has a member of type asio::ssl::context which calls SSL_CTX_new in the constructor and further up the first stack trace until the block_size member of an EVP_CIPHER struct is updated in the evp_cipher_cache_constants function.
The second stack trace is the TLS server accepting a connection from a TLS client (another than the one constructed in the first stack trace). It ends up reading the EVP_CIPHER block size.
The version I use is compiled from commit 885a2a3 from May 11th 2020.
Espen

Hmmm. It seems strange that we cache the constants every time we do a fetch. I might expect it the first time around. Thoughts @levitte?
In practice this is probably not going to cause any issues....we should not expect different constants each time we do a fetch...but still...

Hum... I'll have a look

Please try #11977

Hi. That was fast, but unfortunately it didn't solve my race condition ...
WARNING: ThreadSanitizer: data race (pid=5149)
  Write of size 4 at 0x7b3c000003c4 by main thread:
    #0 evp_cipher_post_new /tmp/../openssl/crypto/evp/evp_enc.c:1468:28 (tlstest+0x7a5723)
    #1 inner_evp_generic_fetch /tmp/../openssl/crypto/evp/evp_fetch.c:284:51 (tlstest+0x7a5c3b)
    #2 evp_generic_fetch /tmp/../openssl/crypto/evp/evp_fetch.c:303:17 (tlstest+0x7a5997)
    #3 EVP_CIPHER_fetch /tmp/../openssl/crypto/evp/evp_enc.c:1479:12 (tlstest+0x7a235d)
    #4 ssl_evp_cipher_fetch /tmp/../openssl/ssl/ssl_lib.c:5886:12 (tlstest+0x6f7054)
    #5 ssl_load_ciphers /tmp/../openssl/ssl/ssl_ciph.c:332:19 (tlstest+0x6e363d)
    #6 SSL_CTX_new_with_libctx /tmp/../openssl/ssl/ssl_lib.c:3167:10 (tlstest+0x6f1298)
    #7 SSL_CTX_new /tmp/../openssl/ssl/ssl_lib.c:3307:12 (tlstest+0x6f189d)
    #8 asio::ssl::context::context(asio::ssl::context_base::method) /tmp/../asio/include/asio/ssl/impl/context.ipp:273:15 (tlstest+0x67d54d)
    #9 TlsClient::TlsClient() /tmp/../tls/src/TlsClient.cpp:49:9 (tlstest+0x67b906)

  Previous read of size 4 at 0x7b3c000003c4 by thread T12:
    #0 EVP_CIPHER_block_size /tmp/../openssl/crypto/evp/evp_lib.c:279:20 (tlstest+0x7a7125)
    #1 EVP_CIPHER_CTX_block_size /tmp/../openssl/crypto/evp/evp_lib.c:284:12 (tlstest+0x7a7125)
    #2 EVP_EncryptUpdate /tmp/../openssl/crypto/evp/evp_enc.c:552:17 (tlstest+0x7a2dc4)
    #3 construct_stateless_ticket /tmp/../openssl/ssl/statem/statem_srvr.c:3992:17 (tlstest+0x73405a)
    #4 tls_construct_new_session_ticket /tmp/../openssl/ssl/statem/statem_srvr.c:4155:17 (tlstest+0x73405a)
    #5 write_state_machine /tmp/../openssl/ssl/statem/statem.c:844:43 (tlstest+0x71f7f5)
    #6 state_machine /tmp/../openssl/ssl/statem/statem.c:444:21 (tlstest+0x71f7f5)
    #7 ossl_statem_accept /tmp/../openssl/ssl/statem/statem.c:256:12 (tlstest+0x72064e)
    #8 SSL_do_handshake /tmp/../openssl/ssl/ssl_lib.c:3829:19 (tlstest+0x6edfe0)
    #9 SSL_accept /tmp/../openssl/ssl/ssl_lib.c:1715:12 (tlstest+0x6eddf1)
    #10 asio::ssl::detail::engine::do_accept(void*, unsigned long) /tmp/../asio/include/asio/ssl/detail/impl/engine.ipp:302:10 (tlstest+0x68fef1)

  Location is heap block of size 232 at 0x7b3c000003c0 allocated by main thread:
    #0 malloc /tmp/../llvm-90-native/llvm-90/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:650:5 (tlstest+0x54fcb4)
    #1 CRYPTO_malloc /tmp/../openssl/crypto/mem.c:184:12 (tlstest+0x7c4da9)
    #2 CRYPTO_zalloc /tmp/../openssl/crypto/mem.c:191:11 (tlstest+0x7c4da9)
    #3 evp_cipher_new /tmp/../openssl/crypto/evp/evp_enc.c:1265:26 (tlstest+0x7a4dc8)
    #4 evp_cipher_from_dispatch /tmp/../openssl/crypto/evp/evp_enc.c:1316:19 (tlstest+0x7a4dc8)
    #5 construct_evp_method /tmp/../openssl/crypto/evp/evp_fetch.c:191:12 (tlstest+0x7a64d8)
    #6 ossl_method_construct_this /tmp/../openssl/crypto/core_fetch.c:34:19 (tlstest+0x7c0a3f)
    #7 algorithm_do_this /tmp/../openssl/crypto/core_algorithm.c:50:13 (tlstest+0x7c0880)
    #8 provider_forall_loaded /tmp/../openssl/crypto/provider_core.c:621:25 (tlstest+0x7cd878)
    #9 ossl_provider_forall_loaded /tmp/../openssl/crypto/provider_core.c:690:15 (tlstest+0x7cd878)
    #10 ossl_algorithm_do_all /tmp/../openssl/crypto/core_algorithm.c:72:9 (tlstest+0x7c076a)
    #11 ossl_method_construct /tmp/../openssl/crypto/core_fetch.c:88:9 (tlstest+0x7c0999)
    #12 inner_evp_generic_fetch /tmp/../openssl/crypto/evp/evp_fetch.c:270:23 (tlstest+0x7a5ba7)
    #13 evp_generic_fetch /tmp/../openssl/crypto/evp/evp_fetch.c:303:17 (tlstest+0x7a5997)
    #14 EVP_CIPHER_fetch /tmp/../openssl/crypto/evp/evp_enc.c:1479:12 (tlstest+0x7a235d)
    #15 ssl_evp_cipher_fetch /tmp/../openssl/ssl/ssl_lib.c:5886:12 (tlstest+0x6f7054)
    #16 ssl_load_ciphers /tmp/../openssl/ssl/ssl_ciph.c:332:19 (tlstest+0x6e363d)
    #17 SSL_CTX_new_with_libctx /tmp/../openssl/ssl/ssl_lib.c:3167:10 (tlstest+0x6f1298)
    #18 SSL_CTX_new /tmp/../openssl/ssl/ssl_lib.c:3307:12 (tlstest+0x6f189d)
    #19 asio::ssl::context::context(asio::ssl::context_base::method) /tmp/.../asio/include/asio/ssl/impl/context.ipp:273:15 (tlstest+0x67d54d)
    #20 TlsProxyServer::TlsProxyServer() /tmp/../tls/src/TlsProxyServer.cpp:293:9 (tlstest+0x694d2f)

It is at the exact same point as before, but in a function with a new name.
I also added the trace from TSAN where the block of data containing the race is created. My interpretation of the error is:

first the TlsProxyServer object is created and as part of that an evp_cipher structure is also created (the third block of stack trace)
second a TlsClient is created
third; in separate threads the TlsServer accepts a connection from the first TlsClient and a second TlsClient is created (the first and second blocks of stack trace)
boom.

There is a lock member in the evp_cipher struct, so someone has thought that access to the struct should be protected for multi threading, but I don't know enough about the OpenSSL code to suggest where locking should be applied. Both evp_cipher_post_new and EVP_CIPHER_block_size gets the cipher structure as parameter and could do the locking, but locking on that level feels like a lot of work ...
Espen

Ah, I see, the post new_method function must be run before the method is stored.

#11980 is a simpler alternative that I hope should work for you.  I had it in the back of my mind when I made #11977, but feared that this variant would do the retrieval too early, but it turns out not to be true.

Hi. Thanks for trying to fix this.
I have now tried both #11980 patched on top of #11977 and by its own (the HEAD is the same as mentioned above), but the problem persists.
I have worked around the problem by making sure that when a TlsClient is created, the instantiation of the asio::ssl::context is done on the same thread as the server handles it's requests, hence the operations are serialized, and the race condition on evp_cipher does not appear. Also for me this is test code; in production the servers and clients run in separate processes/computers.
If someone should have the need for both having a TLS client and a TLS server in the same multi threaded process, I suspect they will encounter this problem. Can I suggest that you create a test case for such a situation? Then it is easy to tell if you fix it.
Espen

Well, the fundamental thing here is that it seems we have two threads fetching the exact same method at the same time.  I thought we had already fended off this, but it seems there's something lacking...
Building a test for this is quite challenging and relies on chance, unfortunately, unless we insert very specific thread yielding calls somewhere...

I know. Not an easy test case.
In my setup it is not many tries before the data race occurs, so I will test for you as much as I can.
Espen

Is this still an issue?

#11980 was abandoned half a year ago.  We haven't heard anything since, despite @mattcaswell's ping, so I'm closing this.
If the problem comes back, please raise a new issue.  The affected functionality has gone through quite a number of changes over time, so if the issue remains, it may come out differently and will need a new investigation.


how can i catch the no match found

i have a requirement to catch all the unanswered questions. please suggest me an idea to find unanswered questions. i have to store unanswered questions into a database.

You can override the NoMatchHandler and log your unanswered questions in there.  Check the readme out for an example. If you are still struggling let me know.

im getting an error. no suitable method found to override.

Hello, firstly I would like to say thank you Gary for this library, it is great and very useful to us.
Unfortunately, my override for the no match handler is not getting called and the default no match found message is being passed back form the QnA service. "No good match found in KB".
Do you have any ideas?
I did not ice that the way this is checked and called is the following in the QnAMakerDialog HandleMessage method:
if (response.Answers.Any() && response.Answers.First().QnaId == -1)
Could it be that the service now returns the default message as an answer?

Hi. I think that there must have been a change, as you say, to the way the service indicates no answer has been found. I'll try and take a look today and get a fix in.

my bot doesn't show icon...what can i do for this?


[enhancement]: T8213 (Doorbell Dual) Support

Describe the solution you'd like
I’ve been following along, and with the posting of 2.0 being updated to the latest @bropat - I’m curious why my Video Doorbell Dual is still showing as unsupported, seeing as the latest @bropat update adds support, and it’s listed in the compatible devices page.

Hello,
Good point missing some code. Just added please test beta.9

Can anyone confirm that T8213 is working?


reduce dependencies using npx depcheck

Removed the following unused production dependencies:

fs
jquery
mongodb
react-leaflet
tailwind-scrollbar-hide

While sharp is marked as an unused dependency, it's actually used in by Next.js for "production Image Optimization."

build log with reduced dependencies attached
reduce-build.log


Fixed #32367 -- Fixed models.W042 is raised on inherited manually specified primary key.

https://code.djangoproject.com/ticket/32367

Superseded by #13925.

Superseded by #13925.


Approved for the Swift 3.1 branch.


Convert spotify module to generic json version

Class is set via json class attribute
Different background colors for classes (examples 'custom-spotify' and 'custom-vlc' in style.css)
Icon is chosen based on json alt attribute (default is musical note icon)

Faster than me, thanks! 😍


Viewname file naming conventions for i18n {View}.{lang}.cshtml

Not always the best solution is to have resources for all values, sometimes modifying the whole html is more maintainable and easy. Specially for partial views.
It would be great if it can support something like the Home.mobile.cshtml behavior.
That way I can have Home.cshtml and Home.fr.cshtml
I think this is particularly usefull for partial views and small websites or pages.
The usual terms and conditions content could be a great candidate for this too.

We have that support planned (although not committed to for v1) using the view expanders feature. There's a sample already at https://github.com/aspnet/Mvc/blob/dev/samples/MvcSample.Web/LanguageViewLocationExpander.cs


Revert "rules: include explosm filename"

This reverts commit c7085c4a533990f39eec139e6bfa70a885fbcd78.
Fixes  #181

@hdhoang @mkresin @fguillot
The URL being part of the joke for maybe 1 in 100 cases (never encountered a joke in the URL) does not justify writing out an ugly src attribute under the image IMHO. You can still view the joke (if there is one) by hovering over the link/image and then looking the URL at the bottom of your favorite browser ;)
PS: failing travis is not related

No opinion on this. I'll send another PR to fix the failing tests later.


RuntimeError: 'replay' nodes were not serializable

Hi,
I am trying to run a distributed D4PG agent based on launchpad, the code is lp.launch(program, launch_type='local_mt', serialize_py_nodes=True).
However, it raises the runtime error, which is "The nodes associated to the label 'replay' (<class 'launchpad.nodes.reverb.node.ReverbNode'>) were not serializable using cloudpickle. Make them pickable, or pass `serialize_py_nodes=False` to `lp.launch` if you want to disable this check, for example when you want to use FLAGS, mocks, threading.Event etc, in your node definition."
I tried setting 'serialize_py_nodes=False', then it fixed. But I still wonder that it wether damage the performance?

Can you give this example a try?

Can you give this example a try?

Thank you for your reply, I tried to run the example and got the output.

Traceback (most recent call last):
  File "/home/neardws/Documents/AoV-Journal-Algorithm/Test/run_d4pg.py", line 5, in <module>
    from acme.agents.jax import d4pg
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/acme/agents/jax/d4pg/__init__.py", line 17, in <module>
    from acme.agents.jax.d4pg.agents import D4PG
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/acme/agents/jax/d4pg/agents.py", line 22, in <module>
    from acme.agents.jax.d4pg import builder as d4pg_builder
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/acme/agents/jax/d4pg/builder.py", line 23, in <module>
    from acme.adders import reverb as adders_reverb
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/acme/adders/reverb/__init__.py", line 20, in <module>
    from acme.adders.reverb.base import DEFAULT_PRIORITY_TABLE
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/acme/adders/reverb/base.py", line 28, in <module>
    import reverb
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/reverb/__init__.py", line 21, in <module>
    ensure_tf_install.ensure_tf_version()
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/reverb/platform/default/ensure_tf_install.py", line 37, in ensure_tf_version
    import tensorflow as tf
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/__init__.py", line 37, in <module>
    from tensorflow.python.tools import module_util as _module_util
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/python/__init__.py", line 37, in <module>
    from tensorflow.python.eager import context
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/python/eager/context.py", line 29, in <module>
    from tensorflow.core.framework import function_pb2
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/core/framework/function_pb2.py", line 16, in <module>
    from tensorflow.core.framework import attr_value_pb2 as tensorflow_dot_core_dot_framework_dot_attr__value__pb2
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/core/framework/attr_value_pb2.py", line 16, in <module>
    from tensorflow.core.framework import tensor_pb2 as tensorflow_dot_core_dot_framework_dot_tensor__pb2
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/core/framework/tensor_pb2.py", line 16, in <module>
    from tensorflow.core.framework import resource_handle_pb2 as tensorflow_dot_core_dot_framework_dot_resource__handle__pb2
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/core/framework/resource_handle_pb2.py", line 16, in <module>
    from tensorflow.core.framework import tensor_shape_pb2 as tensorflow_dot_core_dot_framework_dot_tensor__shape__pb2
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/tensorflow/core/framework/tensor_shape_pb2.py", line 36, in <module>
    _descriptor.FieldDescriptor(
  File "/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/google/protobuf/descriptor.py", line 560, in __new__
    _message.Message._CheckCalledFromGeneratedFile()
TypeError: Descriptors cannot not be created directly.
If this call came from a _pb2.py file, your generated code is out of date and must be regenerated with protoc >= 3.19.0.
If you cannot immediately regenerate your protos, some other possible workarounds are:
 1. Downgrade the protobuf package to 3.20.x or lower.
 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will use pure-Python parsing and will be much slower).

More information: https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates

This looks like your TF installation is corrupted. Note the import tensorflow as tf in the stack trace.
Doesn't the same error happen when you just do import tensorflow as tf?

It seems fixed by reinstalling the lower version of protobuf (i.e., 3.20).
However, it raises an ImportError as:
cannot import name 'experiments' from 'acme.jax' (/home/neardws/anaconda3/envs/aov/lib/python3.9/site-packages/acme/jax/__init__.py)
  File "/home/neardws/Documents/AoV-Journal-Algorithm/Test/run_d4pg.py", line 10, in <module>
    from acme.jax import experiments

and there is nothing in the local file acme.jax.__init__.py and the latest version on GitHub.

I think you need to install Acme from sources.

你的邮件已收到，谢谢！


Remove superfluous word in allocating-and-releasing-memory-for-a-bstr.md

@oold : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Ability to edit Incident timeline

As a Status Admin I want the ability to edit incident timelines so that I can make updates to the timeline notes (Like inaccurate spelling or updates on a url) without having to delete the entire incident.

@ryangravetteadmin It sounds nice! Are you able to contribute a PR? I have several things going on, so it may take a while to get implemented.

Thank you! I've recently updated the CONTRIBUTING.md and steps to set up the local environment gets clearer. Try it out!

I've fixed this issue and it's available since v0.4.1.
To edit the timeline, click the 'edit' icon on the right side:


Migration to Jakarta EE 8

This pull request contains changes described in CAMEL-17136: dependencies are updated to their Jakarta EE 8 analogues then possible.
Current known limitations and notices:

Jetty 9 -> Jetty 10 migration: Websocket. Jetty 10 is compatible with Jakarta EE 8, but many Apache Camel components use Jetty 9 specific websocket realization. This components are now unchanged left. This components are camel-ahc-ws, camel-atmosphere-websocket, camel-websocket.
Jetty 9 -> Jetty 10 migration: Continuation. Jetty specific mechanism Continuation for asynchronous request processing is obsolete and was removed in Jetty 10. Component camel-jetty-common contains CamelContinuationServlet, which actively uses Continuation. Within current changes Continuation is replacing with AsyncContext, but existent junit-tests not give a confidence in full correctness of this change.

Thanks for the PR. We need to align also camel-karaf repository to use the same deps

Appropriated changes are made

@bvfalcon Is this still valid?
c/c: @davsclaus @oscerd

@bvfalcon Is this still valid?

Yes, completely. I actualize periodically with last changes from branch "main" and hope, PR will be reviewed and merged sometime ;)

@bvfalcon Is this still valid?

Yes, completely. I actualize periodically with last changes from branch "main" and hope, PR will be reviewed and merged sometime ;)

Thank you for clarifying ... I have some work ahead that may overlap with this, so I am trying to understand at what point we are :)

I believe we can close this ticket by now, right @oscerd / @davsclaus ?

Yes, I think so. There is also a PR on Karaf side probably, we should close there too.

yes it can be closed


Add a way to see a captured log event

Let's say I have something like this in my production code:
var username = "fred";
MDC.put("user", username);
logger.warn("The user " + username + " has requested xyz");

I would like to be able to check that the message contains a string that matches a certain MDC key:
logCaptureListener.logged(aLog().withMdc("user", ???).withMessage(Mathers.containsString(<whatever was in Mdc>));

Perhaps this feature can be delivered in a similar way to Mockito's or Mockk's "capture" facitilities.

Let me think about it. I guess we could add Context and keep some data there 🤔


list index out of range in types in 1.2.1 (proc)

After upgrading from 1.1.0, I'm getting
File "/usr/local/etc/erdb_bt/db/host.py", line 127, in insertHost
proc_record_Relay = dbe.proc('record_Relay(text, text, boolean, int)')
File "/usr/local/lib/python3.4/site-packages/postgresql/driver/pq3.py", line 2345, in proc
sp = StoredProcedure(proc_id, self)
File "/usr/local/lib/python3.4/site-packages/postgresql/driver/pq3.py", line 1920, in init
for x in range(1, len(proargs)+1)
File "/usr/local/lib/python3.4/site-packages/postgresql/driver/pq3.py", line 1920, in
for x in range(1, len(proargs)+1)
File "/usr/local/lib/python3.4/site-packages/postgresql/types/init.py", line 509, in getitem
return self._elements[item]
IndexError: list index out of range
operations=# \df record_Relay
List of functions
Schema |     Name     | Result data type |                              Argument data types                              |  Type
--------+--------------+------------------+-------------------------------------------------------------------------------+--------
erdb   | record_relay | record_relay_rtt | relay_ip text, relay_fqdn text, countconnection boolean, rdns_invalid integer | normal

Revert commit 3346597 , then it will work.
@jwp

Sorry about this. I believe the problem stemmed from me managing to run the tests against an older build, but I'm not sure how. Naturally, it was bewildering seeing this bug when I had just seen the tests pass.
There is some maintenance work to be done with newer versions of PG and Python which caused me to look at my bug list again.


Minio dashboard no longer works in quickstart with Docker Compose

Describe the bug
A clear and concise description of what the bug is.
To Reproduce

Follow the steps under /quickstart
Open the URL localhost:9000 in a browser
See error in screenshot

Expected behavior
Minio dashboard should open up
Screenshots
localhost:9000/

Environment

OS: macOS 10.15.6
Browser: Firefox, Chrome, Safari
MLX Version: f9a05ba

Additional context
https://github.com/minio/minio/issues/12660

I need to update the docker-compose.yaml file with the Minio console port

FYI for kubernetes I'm using the kfp minio image for consistency. https://github.com/machine-learning-exchange/mlx/blob/main/manifests/read-only-k8s/minio.yaml#L48


Coordinates display state is not respected on canvas refresh

Core 0.242
DnD5e 1.5.6
Map Coordinates 0.1.02 (Compatibility Risk (9.2))
When performing a refresh of the canvas (F5), it does not respect the coordinate display state. If I set it (using the toggle button in the Measurement Controls tool) to show border and individual grid labels, or turn off ALL labels, after a refresh, it reverts to displaying the border labels only state.
Also, as a request, would it be possible to add the display status as a dropdown selection to the "Grid" tab of the scene configuration, thus allowing the display state to be scene specific?

Fraid no on both accounts. Both would be wonky and time consuming to implement for minimal functionality


DxvkShaderKey is incorrect when stream-out is used

There is a scenario when create two GS shaders with the same dxasm code, but with different DxbcXfbInfo.  The two GS should be considered as different shader, because they will generate two different spirv or hardware shaders.
But now in D3D11ShaderModuleSet::GetShaderModule() method, when creating the second shader, it just return the cache of the first one.  I think the DxbcXfbInfo should be a part of the ShaderKey.

Yes, it's happened on an internal d3d11 test case, it's used to test corner cases I guess. The two shaders use the different SoEntries. I've work-round it on local.
`      size_t cacheSize = BytecodeLength;
if ((pDxbcModuleInfo != nullptr) && (pDxbcModuleInfo->xfb != nullptr))
{
cacheSize += sizeof(DxbcXfbInfo);
}
std::vector cachedata(cacheSize);
  memcpy(&cachedata[0], pShaderBytecode, BytecodeLength);
  if ((pDxbcModuleInfo != nullptr) && (pDxbcModuleInfo->xfb != nullptr))
  {
      memcpy(&cachedata[BytecodeLength], pDxbcModuleInfo->xfb, sizeof(DxbcXfbInfo));
  }

// Compute the shader's unique key so that we can perform a lookup
DxvkShaderKey key(GetShaderStage(ProgramType), cachedata.data(), cachedata.size());`

Should be fixed now.

It works, thanks.


Remove rad-bicep upload job

This PR removes the old publish job to the rad-bicep fork. We now push to ACR so we no longer need to update the fork

Closing in favor of #88


(suggestion) Able to build from source

Instead of pre-package and manual set-up. Suggest to be able to build from source.
Rely on package manager to handle dependencies such as PhantomJS, CasperJS etc.

Thanks @wei3hua2 for raising this idea! At the moment, you can use npm install tagui with all its dependencies - https://github.com/kelaberetiv/TagUI#packaged-installation
Alternatively, by downloading the packaged installation from above link, users can run TagUI directly with all dependencies included for Windows, Linux or macOS. I'll close the issue for now but do tell me more about what you mean by build from source, compared to the setup options above.
There's no need to build from source because TagUI's engine is not a binary but a combination of JS, PHP, Python, Bash, Batch scripts. The manual setup-up option in readme is for users who would like to practise setting up the dependencies manually but is not required.

@kensoh apology. I missed the package.json file somehow. Going for eye check tomorrow

No probs James! Appreciate all the different users' feedback.
That was how the tool became better and better with time.

By the way I love the tool a lot and given the potential of RPA and current lacking in open source alternative. I wish this project will be great. =)
Still studying the source code though.