Building package boost-system:x64-windows failed with: BUILD_FAILED

... while installing cpprestsdk:x64-windows

log
./build/vcpkg/vcpkg.exe install cpprestsdk:x64-windows
The following packages will be built and installed:
  * boost-algorithm[core]:x64-windows
  * boost-array[core]:x64-windows
  * boost-asio[core]:x64-windows
  * boost-assert[core]:x64-windows
  * boost-atomic[core]:x64-windows
  * boost-bind[core]:x64-windows
  * boost-build[core]:x64-windows
  * boost-chrono[core]:x64-windows
  * boost-compatibility[core]:x64-windows
  * boost-concept-check[core]:x64-windows
  * boost-config[core]:x64-windows
  * boost-container[core]:x64-windows
  * boost-container-hash[core]:x64-windows
  * boost-context[core]:x64-windows
  * boost-conversion[core]:x64-windows
  * boost-core[core]:x64-windows
  * boost-coroutine[core]:x64-windows
  * boost-date-time[core]:x64-windows
  * boost-detail[core]:x64-windows
  * boost-exception[core]:x64-windows
  * boost-function[core]:x64-windows
  * boost-function-types[core]:x64-windows
  * boost-functional[core]:x64-windows
  * boost-fusion[core]:x64-windows
  * boost-integer[core]:x64-windows
  * boost-intrusive[core]:x64-windows
  * boost-io[core]:x64-windows
  * boost-iterator[core]:x64-windows
  * boost-lambda[core]:x64-windows
  * boost-lexical-cast[core]:x64-windows
  * boost-math[core]:x64-windows
  * boost-modular-build-helper[core]:x64-windows
  * boost-move[core]:x64-windows
  * boost-mpl[core]:x64-windows
  * boost-numeric-conversion[core]:x64-windows
  * boost-optional[core]:x64-windows
  * boost-pool[core]:x64-windows
  * boost-predef[core]:x64-windows
  * boost-preprocessor[core]:x64-windows
  * boost-range[core]:x64-windows
  * boost-ratio[core]:x64-windows
  * boost-rational[core]:x64-windows
  * boost-regex[core]:x64-windows
  * boost-smart-ptr[core]:x64-windows
  * boost-static-assert[core]:x64-windows
  * boost-system[core]:x64-windows
  * boost-thread[core]:x64-windows
  * boost-throw-exception[core]:x64-windows
  * boost-tokenizer[core]:x64-windows
  * boost-tuple[core]:x64-windows
  * boost-type-index[core]:x64-windows
  * boost-type-traits[core]:x64-windows
  * boost-typeof[core]:x64-windows
  * boost-unordered[core]:x64-windows
  * boost-utility[core]:x64-windows
  * boost-vcpkg-helpers[core]:x64-windows
  * boost-winapi[core]:x64-windows
  * brotli[core]:x64-windows
    cpprestsdk[brotli,core,default-features,websockets]:x64-windows
  * openssl[core]:x64-windows
  * openssl-windows[core]:x64-windows
  * websocketpp[core]:x64-windows
  * zlib[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/63: zlib:x64-windows
Building package zlib[core]:x64-windows...
-- Downloading http://www.zlib.net/zlib-1.2.11.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/zlib1211.tar.gz
-- Applying patch cmake_dont_build_more_than_needed.patch
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/zlib/src/1.2.11-f690224aeb
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/zlib_x64-windows/share/zlib/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package zlib[core]:x64-windows... done
Installing package zlib[core]:x64-windows...
Installing package zlib[core]:x64-windows... done
Elapsed time for package zlib:x64-windows: 13.88 s
Starting package 2/63: brotli:x64-windows
Building package brotli[core]:x64-windows...
-- Downloading https://github.com/google/brotli/archive/v1.0.2.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/google-brotli-v1.0.2.tar.gz
-- Applying patch install.patch
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/brotli/src/v1.0.2-052e040e54
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/brotli_x64-windows/share/brotli/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package brotli[core]:x64-windows... done
Installing package brotli[core]:x64-windows...
Installing package brotli[core]:x64-windows... done
Elapsed time for package brotli:x64-windows: 36.14 s
Starting package 3/63: openssl-windows:x64-windows
Building package openssl-windows[core]:x64-windows...
-- Downloading http://strawberryperl.com/download/<IP_ADDRESS>/strawberry-perl-<IP_ADDRESS>-32bit-portable.zip...
-- Downloading https://www.openssl.org/source/openssl-1.0.2q.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/openssl-1.0.2q.tar.gz
-- Applying patch ConfigureIncludeQuotesFix.patch
-- Applying patch STRINGIFYPatch.patch
-- Applying patch EnableWinARM32.patch
-- Applying patch EmbedSymbolsInStaticLibsZ7.patch
-- Applying patch EnableWinARM64.patch
-- Downloading http://www.nasm.us/pub/nasm/releasebuilds/2.14/win32/nasm-2.14-win32.zip...
-- Downloading http://download.qt.io/official_releases/jom/jom_1_1_3.zip...

Installing package openssl-windows[core]:x64-windows... done
Elapsed time for package openssl-windows:x64-windows: 5.382 min
Starting package 4/63: openssl:x64-windows
Building package openssl[core]:x64-windows...
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/openssl_x64-windows/share/openssl//usage
-- Performing post-build validation
-- Performing post-build validation done
Building package openssl[core]:x64-windows... done
Installing package openssl[core]:x64-windows...
Installing package openssl[core]:x64-windows... done
Elapsed time for package openssl:x64-windows: 1.443 s
Starting package 5/63: boost-modular-build-helper:x64-windows
Building package boost-modular-build-helper[core]:x64-windows...
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-modular-build-helper[core]:x64-windows... done
Installing package boost-modular-build-helper[core]:x64-windows...
Installing package boost-modular-build-helper[core]:x64-windows... done
Elapsed time for package boost-modular-build-helper:x64-windows: 1.246 s
Starting package 6/63: boost-vcpkg-helpers:x64-windows
Building package boost-vcpkg-helpers[core]:x64-windows...
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-vcpkg-helpers[core]:x64-windows... done
Installing package boost-vcpkg-helpers[core]:x64-windows...
Installing package boost-vcpkg-helpers[core]:x64-windows... done
Elapsed time for package boost-vcpkg-helpers:x64-windows: 1.204 s
Starting package 7/63: boost-compatibility:x64-windows
Building package boost-compatibility[core]:x64-windows...
-- Downloading https://github.com/boostorg/compatibility/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-compatibility-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-compatibility/src/ost-1.69.0-b809a8cf93
-- Packaging headers
-- Packaging headers done
-- Downloading https://raw.githubusercontent.com/boostorg/boost/boost-1.65.1/LICENSE_1_0.txt...
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-compatibility_x64-windows/share/boost-compatibility/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-compatibility[core]:x64-windows... done
Installing package boost-compatibility[core]:x64-windows...
Installing package boost-compatibility[core]:x64-windows... done
Elapsed time for package boost-compatibility:x64-windows: 2.977 s
Starting package 8/63: boost-config:x64-windows
Building package boost-config[core]:x64-windows...
-- Downloading https://github.com/boostorg/config/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-config-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-config/src/ost-1.69.0-89bfb246de
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-config_x64-windows/share/boost-config/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-config[core]:x64-windows... done
Installing package boost-config[core]:x64-windows...
Installing package boost-config[core]:x64-windows... done
Elapsed time for package boost-config:x64-windows: 4.207 s
Starting package 9/63: boost-assert:x64-windows
Building package boost-assert[core]:x64-windows...
-- Downloading https://github.com/boostorg/assert/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-assert-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-assert/src/ost-1.69.0-08c52545eb
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-assert_x64-windows/share/boost-assert/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-assert[core]:x64-windows... done
Installing package boost-assert[core]:x64-windows...
Installing package boost-assert[core]:x64-windows... done
Elapsed time for package boost-assert:x64-windows: 2.839 s
Starting package 10/63: boost-predef:x64-windows
Building package boost-predef[core]:x64-windows...
-- Downloading https://github.com/boostorg/predef/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-predef-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-predef/src/ost-1.69.0-8f2cd404c9
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-predef_x64-windows/share/boost-predef/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-predef[core]:x64-windows... done
Installing package boost-predef[core]:x64-windows...
Installing package boost-predef[core]:x64-windows... done
Elapsed time for package boost-predef:x64-windows: 4.213 s
Starting package 11/63: boost-winapi:x64-windows
Building package boost-winapi[core]:x64-windows...
-- Downloading https://github.com/boostorg/winapi/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-winapi-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-winapi/src/ost-1.69.0-6c1d425716
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-winapi_x64-windows/share/boost-winapi/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-winapi[core]:x64-windows... done
Installing package boost-winapi[core]:x64-windows...
Installing package boost-winapi[core]:x64-windows... done
Elapsed time for package boost-winapi:x64-windows: 4.13 s
Starting package 12/63: boost-preprocessor:x64-windows
Building package boost-preprocessor[core]:x64-windows...
-- Downloading https://github.com/boostorg/preprocessor/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-preprocessor-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-preprocessor/src/ost-1.69.0-bcf23f78cc
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-preprocessor_x64-windows/share/boost-preprocessor/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-preprocessor[core]:x64-windows... done
Installing package boost-preprocessor[core]:x64-windows...
Installing package boost-preprocessor[core]:x64-windows... done
Elapsed time for package boost-preprocessor:x64-windows: 7.118 s
Starting package 13/63: boost-detail:x64-windows
Building package boost-detail[core]:x64-windows...
-- Downloading https://github.com/boostorg/detail/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-detail-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-detail/src/ost-1.69.0-d5ef7077df
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-detail_x64-windows/share/boost-detail/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-detail[core]:x64-windows... done
Installing package boost-detail[core]:x64-windows...
Installing package boost-detail[core]:x64-windows... done
Elapsed time for package boost-detail:x64-windows: 2.928 s
Starting package 14/63: boost-throw-exception:x64-windows
Building package boost-throw-exception[core]:x64-windows...
-- Downloading https://github.com/boostorg/throw_exception/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-throw_exception-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-throw-exception/src/ost-1.69.0-a86b5dd870
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-throw-exception_x64-windows/share/boost-throw-exception/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-throw-exception[core]:x64-windows... done
Installing package boost-throw-exception[core]:x64-windows...
Installing package boost-throw-exception[core]:x64-windows... done
Elapsed time for package boost-throw-exception:x64-windows: 2.487 s
Starting package 15/63: boost-build:x64-windows
Building package boost-build[core]:x64-windows...
-- Downloading https://github.com/boostorg/build/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-build-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-build/src/ost-1.69.0-1d1e4d577d
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Downloading https://raw.githubusercontent.com/boostorg/boost/boost-1.69.0/boostcpp.jam...
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-build_x64-windows/share/boost-build/copyright
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-build_x64-windows/tools/boost-build/boostcpp.jam
-- Bootstrapping...
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-build[core]:x64-windows... done
Installing package boost-build[core]:x64-windows...
Installing package boost-build[core]:x64-windows... done
Elapsed time for package boost-build:x64-windows: 43.53 s
Starting package 16/63: boost-core:x64-windows
Building package boost-core[core]:x64-windows...
-- Downloading https://github.com/boostorg/core/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-core-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-core/src/ost-1.69.0-af8c37b85e
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-core_x64-windows/share/boost-core/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-core[core]:x64-windows... done
Installing package boost-core[core]:x64-windows...
Installing package boost-core[core]:x64-windows... done
Elapsed time for package boost-core:x64-windows: 3.368 s
Starting package 17/63: boost-static-assert:x64-windows
Building package boost-static-assert[core]:x64-windows...
-- Downloading https://github.com/boostorg/static_assert/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-static_assert-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-static-assert/src/ost-1.69.0-ed1accba2d
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-static-assert_x64-windows/share/boost-static-assert/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-static-assert[core]:x64-windows... done
Installing package boost-static-assert[core]:x64-windows...
Installing package boost-static-assert[core]:x64-windows... done
Elapsed time for package boost-static-assert:x64-windows: 2.826 s
Starting package 18/63: boost-integer:x64-windows
Building package boost-integer[core]:x64-windows...
-- Downloading https://github.com/boostorg/integer/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-integer-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-integer/src/ost-1.69.0-0016500641
-- Packaging headers
-- Packaging headers done
-- Using cached D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/packages/boost-integer_x64-windows/share/boost-integer/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-integer[core]:x64-windows... done
Installing package boost-integer[core]:x64-windows...
Installing package boost-integer[core]:x64-windows... done
Elapsed time for package boost-integer:x64-windows: 3.098 s
Starting package 19/63: boost-system:x64-windows
Building package boost-system[core]:x64-windows...
-- Downloading https://github.com/boostorg/system/archive/boost-1.69.0.tar.gz...
-- Extracting source D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/downloads/boostorg-system-boost-1.69.0.tar.gz
-- Using source at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-system/src/ost-1.69.0-9d1d01900c
-- Building x64-windows-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:56 (message):
    Command failed: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/tools/boost-build/b2.exe;--stagedir=D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-system/x64-windows-rel/stage;--build-dir=D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-system/x64-windows-rel;--user-config=D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-system/x64-windows-rel/user-config.jam;-j4;--debug-configuration;--debug-building;--debug-generators;--disable-icu;--ignore-site-config;--hash;-q;-sZLIB_INCLUDE="D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/include";-sBZIP2_INCLUDE="D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/include";threading=multi;threadapi=win32;runtime-link=shared;link=shared;address-model=64;architecture=x86;toolset=msvc-14.1;-sZLIB_BINARY=zlib;-sZLIB_LIBPATH="D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/lib";-sBZIP2_BINARY=bz2;-sBZIP2_LIBPATH="D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/lib";variant=release;debug-symbols=on
    Working Directory: D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-system/src/ost-1.69.0-9d1d01900c/build
    Error code: 1
    See logs for more information:
      D:\Projects\_tmp\docker\vcpkg-example\build\vcpkg\buildtrees\boost-system\build-x64-windows-rel-out.log

Call Stack (most recent call first):
  installed/x64-windows/share/boost-build/boost-modular-build.cmake:270 (vcpkg_execute_required_process)
  ports/boost-system/portfile.cmake:14 (boost_modular_build)
  scripts/ports.cmake:71 (include)

Error: Building package boost-system:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: boost-system:x64-windows
  Vcpkg version: 2018.11.23-nohash

Hi @artin-phares, thank you for posting the issue, can you provide the build log?
D:\Projects\_tmp\docker\vcpkg-example\build\vcpkg\buildtrees\boost-system\build-x64-windows-rel-out.log
I installed it successfully with VS2017 15.9.11 and VCPKG latest source.

Starting package 1/58: zlib:x64-windows
Building package zlib[core]:x64-windows..
......
Starting package 14/58: boost-system:x64-windows
Building package boost-system[core]:x64-windows...
-- Downloading https://github.com/boostorg/system/archive/boost-1.69.0.tar.gz...
-- Extracting source F:/b/vcpkg/downloads/boostorg-system-boost-1.69.0.tar.gz
-- Using source at F:/b/vcpkg/buildtrees/boost-system/src/ost-1.69.0-9d1d01900c
-- Building x64-windows-rel
-- Building x64-windows-rel done
-- Building x64-windows-dbg
-- Building x64-windows-dbg done
-- Packaging x64-windows-rel
-- Packaging x64-windows-rel done
-- Packaging x64-windows-dbg
-- Packaging x64-windows-dbg done
-- Packaging headers
-- Packaging headers done
-- Using cached F:/b/vcpkg/downloads/boost_LICENSE_1_0.txt
-- Installing: F:/b/vcpkg/packages/boost-system_x64-windows/share/boost-system/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package boost-system[core]:x64-windows... done
Installing package boost-system[core]:x64-windows...
Installing package boost-system[core]:x64-windows... done
Elapsed time for package boost-system:x64-windows: 5.555 s
......
Building package cpprestsdk[brotli,core,default-features,websockets]:x64-windows... done
Installing package cpprestsdk[brotli,core,default-features,websockets]:x64-windows...
Installing package cpprestsdk[brotli,core,default-features,websockets]:x64-windows... done
Elapsed time for package cpprestsdk:x64-windows: 1.394 min

Total elapsed time: 10.84 min

The package cpprestsdk:x64-windows provides CMake targets:

find_package(cpprestsdk CONFIG REQUIRED)
# Note: 1 target(s) were omitted.
target_link_libraries(main PRIVATE cpprestsdk::cpprest cpprestsdk::cpprestsdk_zlib_internal cpprestsdk::cpprestsdk_boost_internal cpprestsdk::cpprestsdk_openssl_internal)

Sure,

build-x64-windows-rel-out.log
notice: found boost-build.jam at D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/tools/boost-build/boost-build.jam
notice: loading Boost.Build from D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/tools/boost-build/src/kernel
notice: Site configuration files will be ignored due to the
notice: --ignore-site-config command-line option.
notice: Loading explicitly specified user configuration file:
    D:\Projects\_tmp\docker\vcpkg-example\build\vcpkg\buildtrees\boost-system\x64-windows-rel\user-config.jam
notice: Searching 'D:\Projects\_tmp\docker\vcpkg-example\build\vcpkg\buildtrees\boost-system\x64-windows-rel' for user-config configuration file 'user-config.jam'.
notice: Loading user-config configuration file 'user-config.jam' from 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/buildtrees/boost-system/x64-windows-rel'.

warning: Did not find command for MSVC toolset. If you have Visual Studio 2017 installed you will need to specify the full path to the command, set VS150COMNTOOLS for your installation, or build from the 'Visual Studio Command Prompt for VS 2017'.

notice: will use 'cl.exe' for msvc, condition <toolset>msvc
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>', setup: 'x86'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>32', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>32', setup: 'x86'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>', setup: 'x86'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>32', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>32', setup: 'x86'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>64', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>/<address-model>64', setup: 'amd64'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>64', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>x86/<address-model>64', setup: 'amd64'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>ia64/<address-model>', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>ia64/<address-model>', setup: 'x86_ia64'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>ia64/<address-model>64', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>ia64/<address-model>64', setup: 'x86_ia64'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>arm/<address-model>', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>arm/<address-model>', setup: 'x86_arm'
notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>arm/<address-model>32', setup: 'D:/Projects/_tmp/docker/vcpkg-example/build/vcpkg/installed/x64-windows/share/boost-build/nothing.bat' notice: [msvc-cfg] condition: '<toolset>msvc/<architecture>arm/<address-model>32', setup: 'x86_arm'
notice: [cmdline-cfg] toolset msvc-14.1 not previously configured; attempting to auto-configure now
error: msvc initialization: parameter 'version' inconsistent
error: no value was specified in earlier initialization
error: an explicit value is specified now

I've fresh reinstalled vcpkg right now,  .\vcpkg.exe install cpprestsdk:x64-windows, and see same error.

Duplicate of #5976, so close it.


V0.9.1

updated OpenAI to 1.3.3 (adds gpt-3.5-turbo-1106)
make errors for environment variables shown on the UI
cleanup syntax for independent models
added an OAIWUI_USERNAME (not enabled by default)

self-approving after local testing


Attribute values are occasionally java security contexts

We've seen using the name of the java security context as the value for all attributes, instead of the attribute values retrieved from the resolver.  e.g.
2017-05-15 09:53:41,018 - DEBUG [net.shibboleth.idp.oidc.flow.PreAuthorizeUserApprovalAction:201] - xxx.xxx.xxx.xxx - Stored authentication [net.shibboleth.idp.oidc.client.userinfo.authn.SpringSecurityAuthenticationToken@67ea9dde: Principal: net.shibboleth.idp.authn.context.SubjectContext@1d62f620; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.core.userdetails.User@44eca05e: Username: net.shibboleth.idp.authn.context.SubjectContext@76972061; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_USER; Granted Authorities: ROLE_USER, AuthenticationClassRefAuthority,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, AuthenticationMethodRefAuthority,authn/RemoteUserInternal] into Spring security context  2017-05-15 09:53:41,817 - DEBUG [net.shibboleth.idp.oidc.client.userinfo.ShibbolethUserInfoRepository:130] - xxx.xxx.xxx.xxx - Final userinfo object constructed from attributes is  {"sub":"net.shibboleth.idp.authn.context.SubjectContext@76972061","name":null,"preferred_username":"net.shibboleth.idp.authn.context.SubjectContext@76972061","given_name":null,"family_name":null,"middle_name":null,"nickname":null,"profile":null,"picture":null,"website":null,"gender":null,"zoneinfo":null,"locale":null,"updated_at":null,"birthdate":null,"email":null,"email_verified":null,"phone_number":null,"phone_number_verified":null}
vs
2017-09-22 11:54:47,944 - DEBUG [net.shibboleth.idp.oidc.flow.PreAuthorizeUserApprovalAction:201] -  - Stored authentication [net.shibboleth.idp.oidc.client.userinfo.authn.SpringSecurityAuthenticationToken@2179319c: Principal: net.shibboleth.idp.authn.context.SubjectContext@656433ac; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.core.userdetails.User@6231f29: Username: bjensen; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_USER; Granted Authorities: ROLE_USER] into Spring security context
This hasn't happened frequently, but we'd like to understand the cause.
idp-process.log

It seems to be something that happens to individual sessions.  I got in the corrupted state:
2017-09-29 14:48:10,325 - DEBUG [net.shibboleth.idp.authn.impl.FinalizeAuthentication:144] - xxx.xxx.xxx.xxx - Profile Action FinalizeAuthentication: Canonical principal name established from session as 'net.shibboleth.idp.authn.context.SubjectContext@16dd235e'
vs (in a fresh session in an incognito window):
2017-09-29 14:52:24,123 - DEBUG [net.shibboleth.idp.authn.impl.FinalizeAuthentication:144] - xxx.xxx.xxx.xxx - Profile Action FinalizeAuthentication: Canonical principal name established from session as 'bjensen'
It happens in both the SAML and OIDC authentication flows.
Potential points of interest - we're using memcache as a session store.  The problem went away when I restarted memcache.  I've only see this happen on machines with the OIDC overlay.
I reloaded that attribute resolver service several times (using reload-service.sh)
The problem persisted across tomcat restarts.

Found something else in the logs..
The times we've seen this, it looks like the user has an existing session that is then routed through RemoteUserInteral
2017-05-15 09:53:41,016 - DEBUG [net.shibboleth.idp.oidc.client.userinfo.authn.SpringSecurityAuthenticationTokenFactory:94] - xxx.xxx.xxx.xxx - Adding authority authn/RemoteUserInternal
...
2017-09-29 14:19:32,184 - DEBUG [net.shibboleth.idp.oidc.client.userinfo.authn.SpringSecurityAuthenticationTokenFactory:94] - xxx.xxx.xxx.xxx - Adding authority authn/RemoteUserInternal

I believe I'm seeing this when I connect and disconnect from my work VPN.  I seems to happen after the second IP change.

It seems to be some interaction between our local "remoteuserplus" and the distributed RemoteUserInternal authentication flows.
remoteuserplus is a copy of RemoteUser, and I do not yet see difference that stands out.. but if my idp.authn.flow is "remoteuserplus|RemoteUserInternal", I can replicate the issue on demand.

log in to oidc client
sub: bjensen
change IP addresses (connect to vpn?)
log in to oidc client
sub: net.shibboleth.idp.authn.context.SubjectContext@1b3944
amr: authn/RemoteUserInternal

The "amr" claim is added when it switched to RemoteUserInternal.

I replaced my remoteuserplus flow with copy of the RemoteUser flow, changing the occurrences of "(RemoteUser|remoteuser)" to "(RemoteUserPlus|remoteuserplus)", and still authentication still falls through to RemoteUserInternal when the user is using OIDC and they switch networks.

This was caused by the order of the authentication handler in conf/authn/general-authn.xml


Bug: TypeError: e is undefined

Describe the bug
A clear and concise description of what the bug is.
v2.0.0-rc6+
TypeError: e is undefined
    qx Home.jsx:140
[main.15ae206d.js:2:692701](https://aci-zot02.insieme.local/static/js/main.15ae206d.js)
    qx https://aci-zot02.insieme.local/static/js/main.15ae206d.js:2

To Reproduce
Go to home page and just open "inspect" on browser
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

I had a go at trying to reproduce this. I wasn't able to see any errors in the console when opening the Home page. Looks like the issue might have already been fixed.
Steps followed:

Download zot-linux-amd64 from Github Releases for version 2.0.2.
Run zot with the config file: examples/config-ui.json.
Access: http://localhost:8080/home.
Observed no errors in the console.

Browser: Firefox 123.0.1 (64-bit)
OS: Ubuntu Linux 22.04 LTS

Let's close this. We can open a new one if we have more details.


How can I use Ziggy with React and Inertia ?

How can I call in a React component the JavaScript route function generated by the Ziggy's @route directive ?
The route function is generated at runtime so it's impossible to import it beforehand in the react component and therefore, Laravel Mix throws an error and can't compile the project.
My stack is Laravel 8, Inertia & React.
Thanks !

You can import the route() function either from Ziggy's vendor directory, with something like
resolve: {
    alias: {
        ziggy: path.resolve('vendor/tightenco/ziggy/src/js/route.js'),
    },
}

added to your Webpack config, or by installing the ziggy-js npm package.
Ziggy provides an artisan command, php artisan ziggy:generate, that will generate the object with all of your route information and put it either at resources/assets/js/ziggy.js or at the path you pass it.
After doing those two things, you should be able to just
import route from 'ziggy'; // or `ziggy-js` if you use the npm package
import Ziggy from './ziggy'; // path to the file generated by the artisan command

and use route() normally.
Take a look at the Artisan Command section in the readme too.
I'm going to close this but let me know if that works and if you have any other questions!

Thanks, it worked !
Do you think it's good idea to add this information to the doc ?

Yep! The alias part is already there, but it could definitely be clearer and it's worth mentioning React in addition to Vue.

@caturandi-labs https://vitejs.dev/config/#resolve-alias


urh: 2.3.0 -> 2.4.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/urh/versions.
meta.description for urh is: '"Universal Radio Hacker: investigate wireless protocols like a boss"'.
Release on GitHub
Compare changes on GitHub

Checks done (click to expand)

built on NixOS
/nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin/.urh-wrapped passed the binary check.
/nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin/urh passed the binary check.
/nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin/.urh_cli-wrapped passed the binary check.
/nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin/urh_cli passed the binary check.
4 of 4 passed binary check by having a zero exit code.
2 of 4 passed binary check by having the new version present in output.
found 2.4.0 with grep in /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0
directory tree listing: https://gist.github.com/b29a2d987a9e0d349712d9827fe4d619
du listing: https://gist.github.com/236d9775c26320e852d9c5cb205057af

Outpath report (click to expand)

Outpath difference report
3 total rebuild paths
1 package rebuilds
0 x86_64-darwin rebuilds
1 x86_64-linux rebuilds
1 aarch64-linux rebuilds
First ten rebuilds by attrpath
urh

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A urh https://github.com/r-ryantm/nixpkgs/archive/713312810779e5cffcce320848e72d241ce900da.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0
ls -la /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin

cc @fpletz for testing.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: urh
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: urh
Partial log (click to expand)
shrinking /nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0/lib/python3.6/site-packages/urh/dev/native/lib/hackrf.cpython-36m-aarch64-linux-gnu.so
shrinking /nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0/lib/python3.6/site-packages/urh/dev/native/lib/rtlsdr.cpython-36m-aarch64-linux-gnu.so
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0/lib  /nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0/bin
patching script interpreter paths in /nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0
checking for references to /build in /nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0...
wrapping `/nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0/bin/urh_cli'...
wrapping `/nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0/bin/urh'...
postPatchMkspecs
/nix/store/hckfi0vknfmiqvvh4r5qvqhw7j91ap0g-urh-2.4.0

Success on x86_64-linux (full log)
Attempted: urh
Partial log (click to expand)
shrinking /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/lib/python3.6/site-packages/urh/dev/native/lib/hackrf.cpython-36m-x86_64-linux-gnu.so
shrinking /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/lib/python3.6/site-packages/urh/dev/native/lib/rtlsdr.cpython-36m-x86_64-linux-gnu.so
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/lib  /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin
patching script interpreter paths in /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0
checking for references to /build in /nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0...
wrapping `/nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin/urh_cli'...
wrapping `/nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0/bin/urh'...
postPatchMkspecs
/nix/store/wbk5hnfz0cxfng9ly43zdkcf60j21hhn-urh-2.4.0

Works with my RTL-SDR stick


fix: price filter fixes

When min or max  of <input type="range" /> is a floating number and the step is an integer, the slider looks weird:

Plain HTML https://jsfiddle.net/v6xpecL0/
To overcome this I set step="any" to the price range slider.
Additionally, I round values on change, because:

It's not convinient to slide between decimals.
It's nicer to have integer in URL than ?maxPrice=11.1199717420213

Previously, applied price filter looked bad after changing only mimumum or only maximum:

The fix is to show the lowest/highest value if it's not applied explicitly.

Previously, applied price filter looked bad after changing only mimumum or only maximum

The screenshots before and after look identical to me.

Ah, you mean this


Remove mixer client stress test.

https://github.com/istio/istio/issues/4281

@qiwzhang: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
23786a73a2b87d2e68038c132be80e387e51c00c
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

is this test going to come back ? or moved to a different suite ? if it was testing something like it appeared to be, it's a bit sad it's just deleted ?

It was not very useful stress test.  It just launches 10 threads with a lot of requests.  At the end, count number of failed requests.  So far, it did not catch anything.  Sometime it introduced false alarm due to late started Envoy or Mixer.

ok I guess it'll get covered by perf tests then! thanks


Vault templates should be hidden or lockable

Vault templates should optionally be hidden

Because the api endpoint can now be locked, this is no longer required.


[TF 2.0] Converting keras model to estimator ignores data-types

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
ProductName:	Mac OS X
ProductVersion:	10.14.2
BuildVersion:	18C54
TensorFlow installed from (source or binary): pip install ...
TensorFlow version (use command below): v1.12.1-3259-gf59745a381 2.0.0-beta0
Python version: 3.6.8

Describe the current behavior
When converting Keras model to estimator it converts all integer inputs to floats or doubles.
This will result in data-type errors in the converted estimator.
I am not entirely sure if this is a bug or "feature" because this function is indeed called in the conversion: https://github.com/tensorflow/estimator/blob/c956dd32561bac645a1cd870d3c8cfe8e9fe969b/tensorflow_estimator/python/estimator/keras.py#L62
However, this is blocking using integer-inputs in the converted estimator.
Describe the expected behavior
Input-data-types are preserved when converting keras-model to estimator.
Code to reproduce the issue
Small example to reproduce the issue:
import numpy as np
import tensorflow as tf
from tensorflow.python.keras import layers
from tensorflow.python.keras.estimator import model_to_estimator_v2

x_shape = (3,)
n_class = 5
batch_size = 10

x = layers.Input(shape=x_shape, name="x", dtype=tf.int64)

class StupidLayer(layers.Layer):
    def build(self, input_shape):
        self.y = tf.random.poisson(
            lam=10, shape=(batch_size,) + x_shape, dtype=tf.int64
        )
        super().build(input_shape)

    def call(self, inputs, **kwargs):
        return tf.cast(inputs * self.y, tf.float32)

y = StupidLayer()(x)

model = tf.keras.Model(inputs=x, outputs=y)

X = np.random.randint(50, size=(batch_size,) + x_shape, dtype="int64")

model.compile(optimizer="sgd", loss="categorical_crossentropy")
model.predict(X)

tf_estimator = model_to_estimator_v2(keras_model=model)
next(tf_estimator.predict(lambda: X))

Because input is converted to float, last line results in
TypeError: Input 'y' of 'Mul' Op has type int64 that does not match type float32 of argument 'x'.

Have tried on Colab with TF 2.0beta and was able to get mentioned error.

Triage notes: we have a fix for this going in right now. @tanzhenyu will update when it's in the nightlies.

This works in tf-nightly-2.0-preview since the fix was submitted yesterday.


merge to master

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.4 out of 5 committers have signed the CLA.:white_check_mark: nullun:white_check_mark: michaeldiamant:white_check_mark: dsaxton:white_check_mark: barnjamin:x: TheChronicMonsterYou have signed the CLA already but the status is still pending? Let us recheck it.

@TheChronicMonster can you please sign the CLA?

CLA is signed. Thank you


lib.dom.d.ts incorrectly types the return type of HTMLMediaElements.play method

TypeScript Version:  2.3.2
Code
    /**
      * Pauses the current playback and sets paused to TRUE. This can be used to test whether the media is playing or paused. You can also use the pause or play events to tell whether the media is playing or not.
      */
    pause(): void;
    /**
      * Loads and starts playback of a media resource.
      */
    play(): void;

Expected behavior:
lib.dom.d.ts should type the returned value of play() as Promise<void>: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/play
Actual behavior:
lib.dom.d.ts types the return type as void

Link to PR: https://github.com/Microsoft/TypeScript/pull/15699

PRs welcomed. You can find more information about contributing lib.d.ts fixes at https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes.

Note that W3C and WHATWG spec disagrees here. It is defined as void on W3C spec and as Promise<void> on WHATWG spec.

Thanks for the quick feedback! I've created the new PR here: https://github.com/Microsoft/TSJS-lib-generator/pull/249

This can now be closed, right?

Fixed in #16005.


Fastlane will always failed after I changed my account password

After I changed my password, running fastlane always result in error:
[15:49:10]: fastlane finished with errors
/Users/siuying/.rvm/gems/ruby-2.1.5/gems/spaceship-0.0.14/lib/spaceship/client.rb:176:in `login': #<Faraday::Response:0x007fad7bb6d9d0> (Spaceship::Client::InvalidUserCredentialsError)
	from /Users/siuying/.rvm/gems/ruby-2.1.5/gems/spaceship-0.0.14/lib/spaceship/client.rb:45:in `login'
	from /Users/siuying/.rvm/gems/ruby-2.1.5/gems/spaceship-0.0.14/lib/spaceship.rb:31:in `login'
	from /Users/siuying/.rvm/gems/ruby-2.1.5/gems/sigh-0.10.0/lib/sigh/spaceship/runner.rb:11:in `run'
	from /Users/siuying/.rvm/gems/ruby-2.1.5/gems/sigh-0.10.0/lib/sigh/manager.rb:7:in `start'
	from /Users/siuying/.rvm/gems/ruby-2.1.5/gems/fastlane-1.7.0/lib/fastlane/actions/sigh.rb:20:in `run'

I expect fastlane to ask me to enter new password, but somehow it just crash.
Manually delete the entry 'fastlane." can workaround the issue.

This should be improved, please submit this issue on https://github.com/fastlane/spaceship


MSTest run settings section is incomplete

The documentation on the following page appears out of date, at least for the <MSTest> settings:
https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019#mstest-run-settings
For instance, I understand that for almost a year now a <Parallelize> configuration can be provided, e.g.:
  <MSTest>
    <Parallelize>
      <Workers>32</Workers>
      <Scope>MethodLevel</Scope>
    </Parallelize>
  </MSTest>

It would great to see what else has been made in the way of improvements.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 21ac034a-a498-f3e3-28d0-175b6fead219
Version Independent ID: 747194a8-ffcf-60b3-b525-6f8fe00066a2
Content: Configure unit tests with a .runsettings file - Visual Studio
Content Source: docs/test/configure-unit-tests-by-using-a-dot-runsettings-file.md
Product: visual-studio-windows
Technology: vs-ide-test
GitHub Login: @gewarren
Microsoft Alias: gewarren

@AbhitejJohn Should <Parallelize> be added to this document?

@gewarren , @alainbryden : it'd probably be nice to add all these new features in a runsettings format under https://github.com/microsoft/testfx-docs and add a comment in docs linking to this, because that's where all documentation for MSTest is kept up-to-date. I've filed this issue in testfx to track that.

Keeping this issue open until the testfx-docs issue is fixed, and then we'll link to that document.


"Levelauswahl" not saving state

What is going on?
When going from ingame to the "Levelauswahl", the game state is not being saved thus when going back undefined behavior will occur.
What should happen?
When going to "Levelauswahl" and back ingame, the game should be in the same state as before.
Steps to reproduce
This is not reproduceable as the "back" button is not implemented yet.

Will close in #48


parties_summary.identifier is null if identifier.scheme is not provided

Sometimes publishers share draft data in which parties.identifier.id and parties.identifier.legalName are provided but parties.identifier.scheme is not.
For those cases, in views, parties_summary.identifier is null because concatenating a null value and a string results in a null value (https://github.com/open-contracting/kingfisher-views/blob/master/sql/002-tmp_release_and_parties.sql#L115).
We nearly got caught out when preparing feedback for Makueni County as one of the checks in the data feedback notebook was reporting that no identifiers were provided based on parties_summary.identifier being null.
@kindly given that .scheme isn't a required field, should parties_summary.identifier be populated, even when .scheme isn't provided or was this by design?
cc @mrshll1001 @odscrachel

In Pelican, coverage of parties.identifier is reported as 100% in the Makueni data, so it would be good to be consistent across the two tools:

Likely also affects buyer_summary, procuringEntity_summary, tenderers_summary and award_suppliers_summary

 kf-views bug: not providing an (optional) identifier scheme causes identifier to be blank

In https://github.com/open-contracting/kingfisher-views/commit/10dd81f5641091a09fcd33ecc427880813f42d9a I replace our use of || in these cases with concat_ws, which will ignore any values that are null and use the rest. By default this returns the empty string '' if both of the values are null. @duncandewhurst Is this okay, or should I add extra logic to make it null in this case?

Thanks @Bjwebb I think returning null would be more consistent with the behaviour of other fields in Kingfisher Views when the source field is missing from the OCDS data

Closed by #150


Encoding fails if there is no "original" layer

Describe the bug

If the AnnData object is created by ehrapy.io.read a layer called "original" is added. The encoding function assumes this is present and fails with an unclear error if it isn't.
To Reproduce
Steps to reproduce the behavior:
from anndata import AnnData
import ehrapy

X = np.array([[1, 3.4, "A string", "A different string"], [2, 5.4, "Silly string", "A different string"], [2, 5.7, "A string", "What string?"]], dtype=np.dtype(object))
adata = AnnData(X=X_strings, dtype=np.dtype(object))

# Encoding fails
ehrapy.preprocessing.encode(adata, autodetect=True)
KeyError: 'original'

# If we add "original" first it works
adata.layers["original"] = adata.X.copy()
ehrapy.preprocessing.encode(adata, autodetect=True)
AnnData object with n_obs × n_vars = 3 × 4
    obs: '2', '3'
    uns: 'categoricals', 'original_values_categoricals', 'current_encodings'
    layers: 'original'

Expected behavior

Either the "original" layer is created automatically or a clearer error saying that it is missing and how to add it
System [please complete the following information]:

OS: MacOS 10.15
Language Version: Python 3.8
Virtual environment: Conda

@Imipenem this one is for today :)

@Zethson
I'm not sure whether, in this case, it should be really created automatically or not (error, but with a clearer error message).
This layer keeps the original values and is created automatically while using read  as mentioned.
But then, there is a chance the data (or X at least) was modified, which
won`t be reflected in this layer.
When not using read, IMO, even if we create it automatically, we should maybe throw a warning that explains this?

As discussed we will simply copy stuff to originals if it does not yet exist.


What's the max URI length

Hey there. I'm evaluating different web servers for our Rails application because we're running into max URI size errors with the current implementation.
Is there a max limit to the URI length that Falcon can process? If yes, is that configurable in case very long URIs are expected?
PS. If this is not appropriate here, I'm happy to move it to a support forum somewhere, but I couldn't find one mentioned in the readme.
Thanks in advance.

There is no maximum URL length except as limited by the underlying protocols.
That being said, I am planning to add some additional protections to HTTP/1 including a maximum pre-amble (request line and headers) data size.

Let me know if you have any other questions.


⚠ ClamAV has degraded performance

In 596ffd1, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 565 ms

Resolved: ClamAV performance has improved in 78a8920.


HTML Reporter: Prevent XSS attacks

Closes #728

Don't we want to clear out its innerHTML first?

Fixed, browserstack tests passing.

Looks good to me.

:+1:

Rebased and landed.


Model Parameter Not Functioning as Expected

When using the command line interface for ChatGPT, the --model parameter seems to not be working as intended. When attempting to set the model to GPT-4, the application returns responses as if it were GPT-3.
Steps to Reproduce

Set the model to GPT-4 using the command:
% gpt --model gpt-4 -p "Are you chatgpt-4?"
The response was:
As an AI model developed by OpenAI, I'm currently based on GPT-3. As of now, GPT-4 has not been released.
Defining a new assistant in the config file and omitting the --model parameter yielded the same response.
No, I'm an AI developed by OpenAI and currently known as ChatGPT-3. As of now, there is no ChatGPT-4.

Expected Behavior
The application should return responses as per the specified model in the command line or as set in the default assistant in the config file.
Actual Behavior
The application returns responses as if it were GPT-3, irrespective of the model set in the command line or the config file.

gpt-4 might not know it’s gpt-4, that’s expected. Try comparing the latency of response with gpt-3.5-turbo

I was skeptical, especially since OpenAI's webUI seems to know which it is, but the code doesn't lie, and if that's not enough, thenI think this is close enough to proof:
$  for model in gpt-3.5-turbo davinci-002 gpt-4 ; do echo $model; gpt --model $model --prompt "Give me a 20 word sentence about carrots where every word starts with the letter G." ; echo; done

gpt-3.5-turbo
Gorgeous, golden carrots grow generously in gardens, giving great gustatory gratification, garnishing gourmet dishes, gratifying gastronomes' gourmet desires.

davinci-002
ERROR:gptcli:Uncaught exception
Traceback (most recent call last):
[...snip...]
    raise ValueError(f"Unknown model: {model}")
ValueError: Unknown model: davinci-002

gpt-4
"Gardeners generally grow great golden gourds, generating generous gourmet gifts, glorifying gardens, gratifying gourmets, greatly gaining gastronomic gratitude globally."

ChatGPT web ui knows which model it is because it's specified in its system prompt (which was leaked many times, you can find it online)


Fix license detection

Should LICENSE.txt be then dropped? Seems duplicated otherwise.

github should have done that... fixed it.


Fixed #26: PDF being generated from the login screen instead of tax results.

Resolves #26 @talumbau

I don't understand the comment with this commit. What does it mean to say that the "PDF [is] generated from the login screen instead of tax results"?

That's the issue that the PR fixes. The pdf generation requires user login. The view code was using the referrer URL to convert to PDF, which would be the login screen instead of the results screen, if the user is not logged in. The PR uses the results Id to look up the URL instead of the referrer URL so the login prompt does not affect the pdf output.

On Nov 25, 2015, at 1:18 PM, T.J. Alumbaugh<EMAIL_ADDRESS>wrote:
I don't understand the comment with this commit. What does it mean to say that the "PDF [is] generated from the login screen instead of tax results"?
—
Reply to this email directly or view it on GitHub.

Oh I understand, thanks! I will test this locally and see how it goes.

OK, this works great for me locally, although the pdf_view still has the permission_required decorator, which I would prefer to remove. I made some commits to make this work on Heroku, then I deployed it to a test application. Here is what I found: the call to pdfkit.from_url (i.e. the real work) takes longer than 30 seconds on the under-powered VM that hosts the actual website. Prior to this, its only job has been to display the pages and parse the data from the worker nodes to make the output tables. It's apparently a much bigger job to create the PDF and return it. Heroku is set up to give an application error if any response takes longer than 30 seconds. So, the options to make this work are:

try a more powerful (non-free) Heroku VM for hosting the site itself) and see if any of those work
change the work pattern to be similar to the current dropq calculation: we move the PDF view over to a worker node, then poll every five seconds to see if the work is done, then pull the data down and return it.

I would have to do some experiments to see if the first option works. If it does, there would be essentially no follow on work (just merging this PR for the most part) but there would be a small increase in monthly cost of the site.
The other option would require more work to refactor where the PDF is created.
This is not the highest priority this week so I'm tempted to just leave this for now. @MattHJensen, do you have thoughts on this, specifically which option you would prefer that I explore?
-T.J.

try a more powerful (non-free) Heroku VM for hosting the site itself) and see if any of those work

This sounds like a good short/mid term solution.

Unfortunately, it seems that the issue is a hang on Heroku, not an underpowered VM. I have investigated pretty fully and can't figure out why the subprocess call to wkhtmltopdf hangs on Heroku (subprocess call happens inside Python package pdfkit. The options are to either open a ticket on Heroku or switch to a different technique to generate the PDF. I think switching to a plug-in on Heroku for PDF generation is probably OK because if we switch away from heroku at some point, then we can just use wkhtmltopdf anyway.

@talumbau I'm sure you've already looked at this: https://github.com/pdfkit/pdfkit/wiki/Use-with-Heroku
Is this currently how we have pdfkit deployed on Heroku?

no longer relevant. closing.


Error after file conversion

How to resolve this error after file conversion?
Error: func=xmlSecCheckVersionExt:file=xmlsec.c:line=188:obj=unknown:subj=unknown:error=19:invalid version:mode=abi compatible;expected minor version=2;real minor version=2;expected subminor version=25;real subminor version=26

    at ChildProcess.<anonymous> (/home/blindi/www/blindi/doctest/node_modules/awesome-unoconv/dist/converter.js:147:23)
    at ChildProcess.emit (events.js:189:13)
    at maybeClose (internal/child_process.js:970:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)

Should make sure your LibreOffice version is 4.2.5

I had corrected it by doing the following:
`unoconv.on('close', function (code) {
if (stderr.length === 0) {
return reject(new Error(Buffer.concat(stderr).toString('utf8')));
}
  resolve(option.output);
});`


Problem with subscriptions on parachain balances.

Hello!
We faced with a problem when we made a transfer and immediately reconnect and subscribe for a balance update - the last event does not come on that subscription.
Environment:
Acala Mandala network

Case looks like:

1. Connected
2. Made transfer
3. Disconnected
4. Connected again
5. Subscribe on balance update by api.query.tokens.accounts

Actual result:
The balance stay on old value and new event doesn't come.
Expected result:
Receive event when balance was changed

It's reproducing not by 100%, on my view around 25% of all tries.
For reproducing it I prepared script:
https://github.com/stepanLav/simple_script/blob/master/src/script.ts
Example output of this script:
Curent balance is<PHONE_NUMBER>0
Balance from subscripttion is<PHONE_NUMBER>0
Seconds after subscription: 1
Seconds after subscription: 2
Seconds after subscription: 3
...
Seconds after subscription: 58
Seconds after subscription: 59
I can't fetch balance by subscription, let's reconnect and do it again
Curent balance is<PHONE_NUMBER>0

But your extrinsic is always included on chain?

But sometimes the subscription works?

But sometimes the subscription works?

Yes, it happens in about 25% of all cases or slightly more.

Stupid question: But should you not subscribe before any change happens?
Or is the subscription also supposed to work retroactively?

api.query.tokens.accounts

Yeah, I agree that this case looks strange, but we were faced with that when adding chains that use multiasset in our app. We had no problem switching connections before when we used subscription with "api.query.system.account".
And we do reconnection when a user is changing his accounts in app. Now we have an issue when the balance for parachains with multiasset can't update and after research found this strange thing, that exactly "api.query.tokens.accounts" may "lost" some events.

@jacogr any idea if that is a bug in js or some bug in the rpc?

If it was a JS API bug, I would be flooded. I've had one report this week around subscriptions on parachains (which works correctly on relay chains and stand-alone chains) not updating. See https://github.com/polkadot-js/apps/issues/6874
So there is really something weird going on, the results reminds me of the runtime version subscription issues we had a while back.

@bkchr @ggwpez Guys, Can I help with something else looking for a problem? Looks like Jaco faced it also.

Does the same happen for you when you don't disconnect in the middle, i.e.
//make a transfer
    await api.tx.currencies.transfer(Receiver, {'token': 'DOT'}, 100000000).signAndSend(newPair)

    /*
    //recreate connection
    await api.disconnect()
    api = await connectionCreator(url)
    /*

    //subscribe on balance
    api.query.tokens.accounts(newPair.address, {'token': 'DOT'}, ({ free }) => {
        console.log(`Balance from subscripttion is ${free}`)
        if (balance_before_transfer.toString() != free.toString()){
            throw new Error("Try again, it's happening 1/5 tymes")
        }
    });

aka 1 in 5 times it doesn't work?

@jacogr Thank you for your attention!

Does the same happen for you when you don't disconnect in the middle, i.e.

No, it doesn't happen. It works well and I getting messages by subscriptions.

Second question - as you 100% sure that the extrinsic is accepted in the timeout you set? (i.e. state should be updated)

Yes, I'm pretty sure the balance was changed because after 60 seconds I re-created the subscription and got the updated balance. As I said it's reproduced time to time.
await delay(60000)

console.log(`I can't fetch balance by subscription, let's reconnect and do it again...`)
clearInterval(interval)

//recreate connection and try fetch balance again
await api.disconnect()
api = await connectionCreator(url)
await print_current_balance(api, newPair)

I recorded my case, on the left is our application that subscribed to the balance, on the right is running the script:
https://user-images.githubusercontent.com/40560660/152374934-bf54aff1-e8bb-4ee2-947b-db22ec68b038.mp4

Ok, if you don't disconnect and it doesn't happen, it def. doesn't point to an issue with the state_subscribeStorage RPC. Cannot see how it would in that case, it should just be consistent behavior between them.
So a valid test may be to to -

subscribe with 1 API
create another instance and subscribe (this is your general disconnect/reconnect step)

They should match all the way through.

@jacogr
I made script which is reproducing problem with 100%:
firstApi.query.tokens.accounts(newPair.address, { 'token': 'DOT' }, async ({ free }) => {
        console.log(`Balance from subscripttion is ${free}`)

        //Create secon connection
        const secondApi = await connectionCreator(url)

        //make a transfer only one times
        if (++count === 1) {
            await firstApi.tx.currencies.transfer(Receiver, { 'token': 'DOT' }, 100000000).signAndSend(newPair)
        }

        //if subscribe to the balance from second connection immediately after first event it lead to the problem.
        if (count === 2) {
            secondApi.query.tokens.accounts(newPair.address, { 'token': 'DOT' }, async ({ free }) => {
                console.log(`Balance from NEW subscripttion is ${free}`)
            })
        }
    });

If we subscribe to the balance using a second api instance immediately after receiving an event on the first instance, we will get the old value through the second instance, which won't be updated.

@stepanLav and that fails for the Acala Parachain? Did you may also try Polkadot?

@bkchr
It's reproducing for Acala Parachain on Polkadot in 100% cases.
Looks like it depends of the pallet "tokens" because I tried reproduce it on Polkadot (main network) with subscription on balance through system.account() and it doesn't reproduce.

@jacogr @bkchr due to our observation that it can be reproduced on the parachain networks (Statemine on Kusama, Acala on Polkadot, etc), we are assuming that it is related to the block finalization on the parachains. What do you think?

@koute could you take a look at this?

Sure thing; I'm on it.

I can successfully reproduce this problem on a local testnet. I'll investigate it in more detail and fix it.

Okay, I know what the issue is. This is what happens:

Best block is AAA. Current balance is 1.
Block BBB is imported, but is not marked as best; transfer extrinsic is executed in this block, changing the balance from 1 to 2.
New subscription is created; balance of 1 is fetched from the best block (which is still AAA) and sent to the client.
Block CCC (which is built on top of block BBB) becomes the best block/is finalized.

Basically the issue here is that we send the storage change notifications only when a block is imported, but the initial value we send to the subscriber when they first connect is what is in the storage for the best block, which might not be the same as the most recently imported one. And once another block becomes the best block we don't send any new storage notifications to bring the client up to speed on the current state of the storage for the current best block.
So essentially the storage change notifications are currently fundamentally broken as they neither guarantee that you'll see all of the storage changes nor guarantee that the storage changes you see will actually be finalized and stay on chain.
So I guess we could fix it in one of the following ways:

Eagerly send out storage change notifications just as we do right now but send a bunch of fixup notifications when a new best block is picked in cases where that would otherwise result in an inconsistent state.
Same as (1), but send fixups on block finalization.
Only send out storage change notifications for finalized blocks.

I'm guessing (1) would be ideal?
And, just an idea, as an extra feature after fixing this maybe we could also add an extra flag to the storage change notifications telling the subscriber whether the change is final or not and also emit events on finalization. So, e.g. the subscriber would potentially see the following:

Block A: "X changed to 1, not final" (the initial change)
Block B: "X changed to 2, not final" (another block is picked as best, but still not finalized)
Block B->C: "X changed to 3, not final" (new best block built on top of the previous one, still not final)
Block B: "X changed to 2, final" (the previously picked block was finalized)
Block B->C: "X changed to 3, not final" (repeat the 3rd notification, since the 4th overwrote it)

So that way the clients could choose whether they want to observe the most recent potentially unfinalized state, only the finalized state, or both, and could do that with a single notification stream. (Alternatively have the client tell us which kind of a stream they want: the best block one, or the finalized block one, and if they need both have them just subscribe twice. Not sure which approach would be better.)
@bkchr Before I get to fixing this just so that I don't waste my time going for the wrong approach - does this sound good to you? Anything I'm missing here?

We had some internal discussion about the problem as described by @koute above.

Eagerly send out storage change notifications just as we do right now but send a bunch of fixup notifications when a new best block is picked in cases where that would otherwise result in an inconsistent state.

I think I would vote for this solution as you already have proposed. I would say we do it the following way:

We track of which block a peer has seen the storage changes.
When we change the best block to something that a peer has not yet seen, we read all the tracked keys.

Regarding supporting finalized vs best block. I don't really know, that mainly depends on how the UI is handling this. I mean the UI can already handle this by being subscribed to the storage changes and also to finalized heads. The moment we have a new finalized head, it could load the observed storage changes.
@jacogr how is polkadot js handling these storage changes? Do you have some in memory fork aware tree structure that keeps track of all the storage changes of each block?

Each subscription only updates when the RPC sends it new values and then it will return those values to the subscriber. So the JS layer doesn't do anything specific to keep track, it just feeds the values through as the PRCs provides them. Basically all state changes are only done on the Node RPC layer.
So for instance, assuming some UI out there that displays a balance for an account -

UI side makes a sub to the key for system account
On initial connect the RPC returns the as-is value
if a change is detected this is passed town the sub
UI displays this new value

My guess would be that if the initial value is provided as a finalized value, it also helps.

Ahh! I thought you would track this based on forks and what is the best block etc.
This also means that UI currently shows anything, could be any fork or just what came later. This sounds like we should redesign this entire thing here...
The UI should probably on listen for finalized changes, but others are may still interested in all the changes, because they can use that to track every key change.

@koute
Hello!
Any news about this problem? We are still encountering it.

@stepanLav Yes, this is unfortunately not that trivial to fix as there are fundamental issues with the way the storage notifications subscriptions are currently implemented, which might necessitate some sort of redesign of the API.

So I had thought about this problem some more, and basically from what I can see we have three potential requirements here:
a) Never re-execute blocks. Do not store a list of changed keys with each block.
b) Allow the user to subscribe to a stream of storage notifications without specifying all of the keys.
c) Make sure the subscribers see don't miss out on any changes and all the changes they'll (eventually) see will be finalized on the chain.
and we can only pick 2 out of 3. Right now we've essentially picked A and B, so if we want to fulfill C it leaves us either going with:

get rid of requirement A: store a list of changed keys with each block (in the database?) so that we'll be able to emit fixup notifications on chain reorganization while not having to re-execute the blocks,
or get rid of requirement B: essentially remove the ability from the API to subscribe to notifications without specifying the exact keys we want, so we won't need to know what changed in a block and will be able to just resend everything that the client is subscribed for when a chain reorganization happens,
or resend everything that the client is subscribed for if it's a subscription for specific keys (so same as number 2), but instead of removing support for wildcard subscriptions just start sending them starting from the next finalized block, after which the client will keep track of all of the changes that are made from that point on and can handle the reorganizations itself (because it'll get notified about every block that'll be built on top of the already finalized block).

So @bkchr @jacogr which option do we go for? (Unless, of course, someone has a better idea.)
Personally I'd either go for 1 (which would keep the client simple since it doesn't have to do anything extra, and keep the API the same, but make substrate more complex), or 3 (which would keep substrate simple since we don't have to store any extra data, keep the API the same, but will make the client more complex, and will change the semantics a little). I'm guessing number 2 is not acceptable since someone somewhere surely needs this functionality?
Either way I'd be happy to push this and do the legwork as long as we can decide on something.
(I'm not getting into whether the client should follow the finalized block, or the best block, or just simply the most recent block, since in all of those cases it will still be necessary to somehow keep a consistent view of the storage. We can decide on that later.)

Appendix: why can't we keep the wildcard notifications and not track what changed in the storage for each block?
For the sake of argument consider the following simple scenario:
A──> B
└──> C

A is the finalized block. B is the best block.
The subscriber connects and subscribes to any new changes. New block D is imported on top of C, and that new D block gets finalized:
A──> B
└──> C ──> D

The client gets sent all of the changes from the D block, and that's all fine, however since there was a reorganization it's missing notifications about all of the changes from C.
And we can't get those changes because the client subscribed to any changes so we don't have a specific list of keys whose values we could fetch from the storage and send to the client, and we can't get a list of all of the changes from C since we don't store them and can't re-execute the block.

3. or resend everything that the client is subscribed for if it's a subscription for specific keys (so same as number 2), but instead of removing support for wildcard subscriptions just start sending them starting from the next finalized block, after which the client will keep track of all of the changes that are made from that point on and can handle the reorganizations itself (because it'll get notified about every block that'll be built on top of the already finalized block).

I think we should do this.
While I don't really get why you want to send wildcards from the next finalized block? If you have a wildcard subscription you probably do some kind of indexing, aka are interested in all the blocks. However, that is no problem. I would just ignore the wildcard subscriptions when it is about to resend missed keys. Clients that are interested in all the changes of a block can then use state_traceBlock to re-request the missed blocks. AFAIK @xlc is already doing it exactly in this way.

IMHO, the wildcard subs where it means “any key changes in this block” should be unsafe. (It really has very specific use, once again, imho).
The majority of the subs are for specific keys in general dapps - “tell me when x changes”. I believe this is what we should aim to get right.

Considering wildcard subscriptions will require extra work on the client to get right (unless it only wants to dump all changes and doesn't care about consistency of the final state) I like the idea of making those RPC-unsafe. We can then just document the caveats and leave it as-is.
Are we sure that won't break someone's usecase though? Is everyone who's using wildcard subscriptions already using their own node which is already running in allow-unsafe-RPC mode or can be switched into it? And @jacogr does polkadot.js even support wildcard subscriptions in the first place?

Since the RPC exposes it, yes, you can make wildcard subs with polkadot-js. Not on the general api.query.* interfaces there it is pin-point, but you can call the RPC directly.
I'm not quite sure it can be made unsafe on the RPC layer, well, probably not via the same interface we already have. (Granted, it has literally been a very long time since I delved into that). And yes, doing that will break it for somebody.

I'm also fine with making wildcard support unsafe and fix the normal use case :)
I still don't understand how wildcard support would work for finalized blocks because that would again mean we would need to store the changes that happened in a block. But as we don't want to do it, I don't really need to understand it :P

I'm also fine with making wildcard support unsafe and fix the normal use case :)

Okay, so if there are no further objections I'll start working on a PR with a fix soon-ish. (:

I still don't understand how wildcard support would work for finalized blocks because that would again mean we would need to store the changes that happened in a block. But as we don't want to do it, I don't really need to understand it :P

Yes, you'd need to store the changes, so if we don't want to store those then this cannot be done in substrate. But it can be done by the client themselves, they just need to temporarily buffer all of the changes for the non-finalized blocks since the last finalized block, and then once a new block gets finalized retrace the path from the last finalized block through all of the the newly finalized blocks and collect all of the storage changes along the way.
If polkadot.js had some convenient API for wildcard subscriptions we'd do it there, but since you have to call the RPC directly to do this anyway, so we don't have to and can just leave it up to the users'. (Especially if we'd make the wildcards unsafe and properly document that "here be dragons" so people are aware of how it works.)


Update to latest v8 release

see: https://nodejs.org/en/blog/release/v8.16.1/

Many Thanks @jason-fox


Update docker image to expose meilisearch as the entry point rather than tini

Currently, Meilisearch exposes tini as the dockerfile entry point.
This creates a rather cryptic error when you try to run meili like normal e.g.
& docker run --name meilisearch -p 7700:7700 getmeili/meilisearch --master-key="foobar"

Produces:
[FATAL tini (7)] exec --master-key=foobar failed: No such file or directory

Which isn't the most helpful error in the world.
Either that or the documentation probably want's to be changed slightly to make it more clear that you need to explicitly re-run meili as:
& docker run --name meilisearch -p 7700:7700 getmeili/meilisearch ./meilisearch --master-key="foobar"

But IMO
getmeili/meilisearch ./meilisearch --master-key="foobar"

Doesn't seem to be the best situation.

This may be something to do for #2178

Hey @ChillFish8, @brunoocasali found out that we could simply run;
ENTRYPOINT ["tini", "--", "/bin/meilisearch"]

as our entry point, and now when we run
docker run -p 7700:7700 getmeili/meilisearch --master-key masterkey

It does work :grin:
Do you think it's enough, or do you think we should really get rid of tini?
I don't know how we could remove tini, though because then, killing the container with C^c doesn't work :unamused:

I think that would work :)

Hey! Sadly we decided to remove this change because it would make it impossible to debug the container since you would only be able to run meilisearch and nothing else :(
We’ll keep the issue open in case we find a solution one day, but I don’t think there is one.
The best we could do, I think, would be to propose a “light” or “minimal” image that contains nothing but meilisearch, but that’s not currently planned :pensive:

Hi, is this still something you are planning to work on ? The documentation isn't clear on how to start your docker image, and it does fail with [FATAL tini (7)] exec -e failed: No such file or directory which is problematic

Hello @Seluj78, the error message you have is not related to this issue. Our docker image is working. To get some help I recommend you go to our Discord

I missread the error message 🤦  I placed my environment variables at the wrong spot. Sorry !


fix(check-message): can't run the commit message validator

the error:
sed: no-jira,allow-temp,jira-in-header,header-length:,jira-types:: No such file or directory

issue introduced in 0579955c2d12d2522e4bb109585906795fcb52f4

MacOsx only issue, can be solved by installing gnu-sed and gnu-getopt


Multiple Anchors affect range

I have a setup with three anchors running DWM1000Ranging_ANCHOR and 1 tag running DWM1000Rangin_TAG. I have noticed that as more anchors are introduced the spatial accuracy drops dramatically (1 anchor has really good accuracy, 2 anchors have reduced accuracy and 3 is horrible). Has anyone come across this?
Could it be interference? Should I try changing the channel?

Hey @christoshadjiaslanis ,
I have noticed it few months ago also. As you probably know, Tag broadcasts POLL msg to all Anchors. Then anchors replay with POLL_ACK msg. This message is send in pre-determined order.  Anchor which is first in DeviceLists has other response time than the others. They cannot response simultaneously because tag needs some time to process the signal.  The delay supposed in this library:
Anchor1 - 7000 microseconds
Anchor2 - 21000 microseconds
Anchor3 - 35000 microseconds
Do you have a constant offset? You can try play with antennaDelayBytes value, substract offset before printing it or something else. I'm not sure that changing the channel will bring a lot of improvement. Check maybe various modes like: LONGDATA_FAST_ACCURACY or MODE_LONGDATA_RANGE_ACCURACY.
Best regards,
Pride

@prideofisland thanks for getting back to me. I will look into it and let you know.

seems to be a duplicate of #50

closed in favour of #181

HI #50 and #181 are different (its not about multiple tag and it's a precise issue here).
Did you find a solution for this problem ?


Fix/ostree branchname 2

Another fix for that: do not export variables, it's not needed and completely wipes out the cache.

Yes, I've changed OSTREE_BRANCHNAME and it was only a couple of tasks. I would like to run CI anyway on that though if we can fix it...


Add space-cli commands to view, change and delete accounts

We need the following commands

space-cli accounts view -> This should list all the accounts. The keys should be replaces by *s. We can have an optional --show-keys flags which displays the keys as well. We can optionally pass an argument (account id) which displays only the account provided

space-cli accounts set <id> -> this will set the provided account as the selected account if it exists.

space-cli accounts delete <id> -> This will delete the provided account if it exists.

@HeyItsJs how should the edit command look like?

fixed in #1024


Compiling errors

In file included from /caffe2/gen/caffe2/proto/caffe2.pb.cc:5:
caffe2/gen/caffe2/proto/caffe2.pb.h:9:10: fatal error: 'google/protobuf/stubs/common.h' file not found
#include <google/protobuf/stubs/common.h>
         ^
1 error generated.

'file not found' why not, it's on our system.

Also still getting #39
nvcc fatal   : Unsupported gpu architecture 'compute_61'

(closing since this should be fixed after the cmake migration?)


Add search bar to options menu

Description of the new feature / enhancement
Add search bar to options menu
Scenario when this would be used?
This would be especially useful to remap the shortcut and disable it in case it could be an issue or degrade the user experience (like playing a videogame and triggering the app by mistake)
Supporting information
No response

Please be more specific. What menu are you referring to?


ft: double version line in package.json

Hello vrancurel,
My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.
Status report is not available.

Waiting for approval
The following approvals are needed before I can proceed with the merge:

the author

one peer

/approve

Waiting for approval
The following approvals are needed before I can proceed with the merge:

the author

one peer

The following options are set: approve

In the queue
The changeset has received all authorizations and has been added to the
relevant queue(s). The queue(s) will be merged in the target development
branch(es) as soon as builds have passed.
The changeset will be merged in:

:heavy_check_mark: development/2.0

The following branches will NOT be impacted:

development/1.0
development/1.1

There is no action required on your side. You will be notified here once
the changeset has been merged. In the unlikely event that the changeset
fails permanently on the queue, a member of the admin team will
contact you to help resolve the matter.
IMPORTANT
Please do not attempt to modify this pull request.

Any commit you add on the source branch will trigger a new cycle after the
current queue is merged.
Any commit you add on one of the integration branches will be lost.

If you need this pull request to be removed from the queue, please contact a
member of the admin team now.
The following options are set: approve

I have successfully merged the changeset of this pull request
into targetted development branches:

:heavy_check_mark: development/2.0

The following branches have NOT changed:

development/1.0
development/1.1

Please check the status of the associated issue None.
Goodbye vrancurel.


error: paths must start with a leading slash

when i make a post request with both ipfs:// and ipfs:///, i get the following a leading slash error
here is the result from running npm run test
><EMAIL_ADDRESS>test
> standard --fix && node test

TAP version 13
# Load a file via fetch
ok 1 Able to make create fetch instance
ok 2 Got a response object
ok 3 Got OK in response
ok 4 Got expected content type
ok 5 Got expected file content
# Load a file from just the CID
ok 6 Able to make create fetch instance
ok 7 Got a response object
ok 8 Got OK in response
ok 9 Got expected content type
ok 10 Got expected file content
# Load a range from a file
ok 11 Able to make create fetch instance
ok 12 Got a response object
ok 13 Got partial response
ok 14 Got expected file content
# Get expected headers from HEAD
ok 15 Able to make create fetch instance
ok 16 Got a response object
ok 17 Got OK in response
ok 18 Got expected content length
# Load a directory listing via fetch
ok 19 Able to make create fetch instance
ok 20 Got a response object
ok 21 Got OK in response
ok 22 Got directory listing
ok 23 Listing has first file
ok 24 Listing has second file
ok 25 Got OK in response
ok 26 Got files in JSON form
# Resolve index.html from a directory
ok 27 Able to make create fetch instance
ok 28 Got a response object
ok 29 Got OK in response
not ok 30 Got index from directory
  ---
    operator: equal
    expected: 'Hello World!'
    actual:   ''
    at: Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:224:7)
    stack: |-
      Error: Got index from directory
          at Test.assert [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:314:54)
          at Test.bound [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.strictEqual (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:478:10)
          at Test.bound [as equal] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:224:7)
  ...
ok 31 Got OK in response
ok 32 Got files in JSON form
ok 33 Got a response object
ok 34 Got OK in response
not ok 35 Got index from directory
  ---
    operator: equal
    expected: 'Hello World!'
    actual:   ''
    at: Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:241:7)
    stack: |-
      Error: Got index from directory
          at Test.assert [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:314:54)
          at Test.bound [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.strictEqual (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:478:10)
          at Test.bound [as equal] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:241:7)
  ...
# POST a file into IPFS
ok 36 Able to make create fetch instance
Error: paths must start with a leading slash
    at toMfsPath (F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\utils\to-mfs-path.js:120:19)
    at async F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\write.js:101:21
    at async F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\utils\create-lock.js:36:18
    at async mfsWrite (F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\write.js:99:5)
    at async uploadData (F:\Proj\Development\js-ipfs-fetch\index.js:139:9)
    at async F:\Proj\Development\js-ipfs-fetch\index.js:197:26
    at async fetch (F:\Proj\Development\js-ipfs-fetch\node_modules\make-fetch\index.js:35:9)
    at async Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:261:22)
ok 37 Got a response object
not ok 38 Got OK in response
  ---
    operator: equal
    expected: 200
    actual:   500
    at: Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:267:7)
    stack: |-
      Error: Got OK in response
          at Test.assert [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:314:54)
          at Test.bound [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.strictEqual (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:478:10)
          at Test.bound [as equal] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:267:7)
  ...
not ok 39 returned IPFS url with CID
  ---
    operator: match
    expected: |-
      /^ipfs:\/\/\w+\/example.txt$/
    actual: |-
      'Error: paths must start with a leading slash\n    at toMfsPath (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\ipfs-core\\src\\components\\files\\utils\\to-mfs-path.js:120:19)\n    at async
F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\ipfs-core\\src\\components\\files\\write.js:101:21\n    at async F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\ipfs-core\\src\\components\\files\\utils\\create-lock.js:36:18\n    at async mfsWrite (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\ipfs-core\\src\\components\\files\\write.js:99:5)\n    at async uploadData (F:\\Proj\\Development\\js-ipfs-fetch\\index.js:139:9)\n    at async F:\\Proj\\Development\\js-ipfs-fetch\\index.js:197:26\n    at async fetch (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\make-fetch\\index.js:35:9)\n    at async Test.<anonymous> (F:\\Proj\\Development\\js-ipfs-fetch\\test.js:261:22)'
    at: Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:270:7)
    stack: |-
      Error: returned IPFS url with CID
          at Test.assert [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:314:54)
          at Test.bound [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.match (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:733:14)
          at Test.bound [as match] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:270:7)
  ...
Error: To parse non base32 or base58btc encoded CID multibase decoder must be provided
    at parseCIDtoBytes (F:\Proj\Development\js-ipfs-fetch\node_modules\multiformats\cjs\src\cid.js:235:15)
    at Function.parse (F:\Proj\Development\js-ipfs-fetch\node_modules\multiformats\cjs\src\cid.js:204:29)
    at cidAndRest (F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-unixfs-exporter\cjs\src\index.js:38:20)
    at walkPath (F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-unixfs-exporter\cjs\src\index.js:45:26)
    at walkPath.next (<anonymous>)
    at Object.last [as default] (F:\Proj\Development\js-ipfs-fetch\node_modules\it-last\index.js:13:20)
    at exporter (F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-unixfs-exporter\cjs\src\index.js:67:48)
    at getStat (F:\Proj\Development\js-ipfs-fetch\index.js:43:14)
    at F:\Proj\Development\js-ipfs-fetch\index.js:243:28
    at fetch (F:\Proj\Development\js-ipfs-fetch\node_modules\make-fetch\index.js:35:15)
not ok 40 Got OK in response
  ---
    operator: equal
    expected: 200
    actual:   500
    at: Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:273:7)
    stack: |-
      Error: Got OK in response
          at Test.assert [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:314:54)
          at Test.bound [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.strictEqual (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:478:10)
          at Test.bound [as equal] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:273:7)
  ...
not ok 41 Able to load POSTed file
  ---
    operator: equal
    expected: |-
      'Hello World!'
    actual: |-
      'Error: To parse non base32 or base58btc encoded CID multibase decoder must be provided\n    at parseCIDtoBytes (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\multiformats\\cjs\\src\\cid.js:235:15)\n    at Function.parse (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\multiformats\\cjs\\src\\cid.js:204:29)\n    at cidAndRest (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\ipfs-unixfs-exporter\\cjs\\src\\index.js:38:20)\n    at walkPath (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\ipfs-unixfs-exporter\\cjs\\src\\index.js:45:26)\n    at walkPath.next (<anonymous>)\n    at Object.last [as default] (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\it-last\\index.js:13:20)\n    at exporter (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\ipfs-unixfs-exporter\\cjs\\src\\index.js:67:48)\n    at getStat (F:\\Proj\\Development\\js-ipfs-fetch\\index.js:43:14)\n    at F:\\Proj\\Development\\js-ipfs-fetch\\index.js:243:28\n    at fetch (F:\\Proj\\Development\\js-ipfs-fetch\\node_modules\\make-fetch\\index.js:35:15)'
    at: Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:276:7)
    stack: |-
      Error: Able to load POSTed file
          at Test.assert [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:314:54)
          at Test.bound [as _assert] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.strictEqual (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:478:10)
          at Test.bound [as equal] (F:\Proj\Development\js-ipfs-fetch\node_modules\tape\lib\test.js:99:32)
          at Test.<anonymous> (F:\Proj\Development\js-ipfs-fetch\test.js:276:7)
  ...
# POST formdata to IPFS
ok 42 Able to make create fetch instance
F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\utils\to-mfs-path.js:120
    throw errCode(new Error('paths must start with a leading slash'), 'ERR_INVALID_PATH')
                  ^

Error: paths must start with a leading slash
    at toMfsPath (F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\utils\to-mfs-path.js:120:19)
    at async F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\write.js:101:21
    at async F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\utils\create-lock.js:36:18
    at async mfsWrite (F:\Proj\Development\js-ipfs-fetch\node_modules\ipfs-core\src\components\files\write.js:99:5) {
  code: 'ERR_INVALID_PATH'
}

Try 3.5.0, I think it's fixed.
I'm now running tests on the GitHub CI to make sure they pass on Android.
https://github.com/RangerMauve/js-ipfs-fetch/runs/5517232657?check_suite_focus=true