Couldn't find OpenSSL on build

Trying to build RenderStudioKit on Ubuntu 22.04.1 with OpenUSD successfully installed.

Running:
cmake -B Build -DCMAKE_PREFIX_PATH=/home/leo/Github/OpenUSD -DCMAKE_INSTALL_PREFIX=/home/leo/Github/OpenUSD
Got:
CMakeOutput.log
CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY
OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.22/Modules/FindOpenSSL.cmake:574 (find_package_handle_standard_args)
Sources/CMakeLists.txt:17 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/leo/Github/RenderStudioKit/Build/CMakeFiles/CMakeOutput.log"

Running:
openssl version -a
Gives:
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
built on: Fri Oct 13 12:02:49 2023 UTC
platform: debian-amd64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-8L8jlV/openssl-3.0.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x3e983a0b078bffff:0x8

Hello, let me help you with build process
At first, could you please verify that libssl-dev is installed?
sudo apt-get install libssl-dev

Hi, thanks for the assistance. I've built the project using the following command since using just the OpenUSD project path was giving a pxr package loss error (getting uripaser, fmt and zip inside Sources/External was also needed):
cmake -B Build -DCMAKE_PREFIX_PATH=/home/leo/Github/OpenUSD/Install CDCMAKE_INSTALL_PREFIX=/home/leo/Github/OpenUSD/Install
Cmake printed:
CMake Warning:
Ignoring extra path from command line:
"CDCMAKE_INSTALL_PREFIX=/home/leo/Github/OpenUSD/Install"
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "3.0.2")
-- Found Boost: /home/leo/Github/OpenUSD/Install/lib/cmake/Boost-1.78.0/BoostConfig.cmake (found version "1.78.0") found components: python log
-- Found Python3: /usr/include/python3.10 (found suitable exact version "3.10.12") found components: Development Development.Module Development.Embed
-- Found Python3: /usr/bin/python (found suitable version "3.10.12", minimum required is "3.7") found components: Interpreter Development Development.Module Development.Embed
CMake Warning (dev) at /home/leo/.local/lib/python3.10/site-packages/cmake/data/share/cmake-3.27/Modules/FetchContent.cmake:1316 (message):
The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
not set.  The policy's OLD behavior will be used.  When using a URL
download, the timestamps of extracted files should preferably be that of
the time of extraction, otherwise code that depends on the extracted
contents might not be rebuilt if the URL changes.  The OLD behavior
preserves the timestamps from the archive instead, but this is usually not
what you want.  Update your project to the NEW behavior or specify the
DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
robustness issue.
Call Stack (most recent call first):
Sources/CMakeLists.txt:107 (FetchContent_Declare)
This warning is for project developers.  Use -Wno-dev to suppress it.
CMake Warning (dev) at CMakeLists.txt:48 (install):
Target fmt has PUBLIC_HEADER files but no PUBLIC_HEADER DESTINATION.
This warning is for project developers.  Use -Wno-dev to suppress it.
CMake Warning (dev) at CMakeLists.txt:48 (install):
Target uriparser has PUBLIC_HEADER files but no PUBLIC_HEADER DESTINATION.
This warning is for project developers.  Use -Wno-dev to suppress it.
-- Configuring done (3.6s)
-- Generating done (0.1s)
-- Build files have been written to: /home/leo/Github/RenderStudioKit/Build

Now trying to compile with cmake --build Build --config Release the output is looking like this:
[  1%] Checking and installing python dependencies if required
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: fastapi==0.103.2 in /home/leo/.local/lib/python3.10/site-packages (from -r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 1)) (0.103.2)
Requirement already satisfied: uvicorn==0.22.0 in /usr/local/lib/python3.10/dist-packages (from -r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 2)) (0.22.0)
Requirement already satisfied: pyinstaller==5.13.2 in /usr/local/lib/python3.10/dist-packages (from -r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 3)) (5.13.2)
Requirement already satisfied: pyinstaller-hooks-contrib==2023.10 in /usr/local/lib/python3.10/dist-packages (from -r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 4)) (2023.10)
Requirement already satisfied: websockets==10.4 in /usr/local/lib/python3.10/dist-packages (from -r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 5)) (10.4)
Requirement already satisfied: httpx==0.24.1 in /usr/local/lib/python3.10/dist-packages (from -r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 6)) (0.24.1)
Requirement already satisfied: nuitka==1.8.5 in /usr/local/lib/python3.10/dist-packages (from -r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 7)) (1.8.5)
Requirement already satisfied: anyio<4.0.0,>=3.7.1 in /usr/local/lib/python3.10/dist-packages (from fastapi==0.103.2->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 1)) (3.7.1)
Requirement already satisfied: typing-extensions>=4.5.0 in /usr/local/lib/python3.10/dist-packages (from fastapi==0.103.2->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 1)) (4.8.0)
Requirement already satisfied: starlette<0.28.0,>=0.27.0 in /home/leo/.local/lib/python3.10/site-packages (from fastapi==0.103.2->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 1)) (0.27.0)
Requirement already satisfied: pydantic!=1.8,!=1.8.1,!=2.0.0,!=2.0.1,!=2.1.0,<3.0.0,>=1.7.4 in /home/leo/.local/lib/python3.10/site-packages (from fastapi==0.103.2->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 1)) (1.10.13)
Requirement already satisfied: click>=7.0 in /usr/lib/python3/dist-packages (from uvicorn==0.22.0->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 2)) (8.0.3)
Requirement already satisfied: h11>=0.8 in /home/leo/.local/lib/python3.10/site-packages (from uvicorn==0.22.0->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 2)) (0.12.0)
Requirement already satisfied: altgraph in /usr/local/lib/python3.10/dist-packages (from pyinstaller==5.13.2->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 3)) (0.17.4)
Requirement already satisfied: setuptools>=42.0.0 in /usr/lib/python3/dist-packages (from pyinstaller==5.13.2->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 3)) (59.6.0)
Requirement already satisfied: certifi in /usr/lib/python3/dist-packages (from httpx==0.24.1->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 6)) (2020.6.20)
Requirement already satisfied: idna in /usr/lib/python3/dist-packages (from httpx==0.24.1->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 6)) (3.3)
Requirement already satisfied: httpcore<0.18.0,>=0.15.0 in /home/leo/.local/lib/python3.10/site-packages (from httpx==0.24.1->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 6)) (0.15.0)
Requirement already satisfied: sniffio in /usr/local/lib/python3.10/dist-packages (from httpx==0.24.1->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 6)) (1.3.0)
Requirement already satisfied: zstandard>=0.15 in /usr/local/lib/python3.10/dist-packages (from nuitka==1.8.5->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 7)) (0.22.0)
Requirement already satisfied: ordered-set>=4.1.0 in /usr/local/lib/python3.10/dist-packages (from nuitka==1.8.5->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 7)) (4.1.0)
Requirement already satisfied: exceptiongroup in /usr/local/lib/python3.10/dist-packages (from anyio<4.0.0,>=3.7.1->fastapi==0.103.2->-r /home/leo/Github/RenderStudioKit/Workspace/requirements.txt (line 1)) (1.2.0)
[  1%] Built target InstallPythonDeps
[  3%] Building executable of RenderStudioWorkspace using nuitka
Nuitka-Options:INFO: Used command line options: --output-dir=/home/leo/Github/RenderStudioKit/Build/nuitka --standalone --assume-yes-for-downloads --windows-icon-from-ico=/home/leo/Github/RenderStudioKit/Resources/Icon.ico --msvc=14.2 /home/leo/Github/RenderStudioKit/Workspace/RenderStudioWorkspace.py
Nuitka-Options:WARNING: Requesting Windows specific compilers has no effect on other platforms.
Nuitka:INFO: Starting Python compilation with Nuitka '1.8.5' on Python '3.10' commercial grade 'not installed'.
Nuitka:INFO: Using Debian packages for 'certifi,chardet,click,idna,yaml'.
Nuitka:WARNING: Standalone with Python package from Debian installation may not be working.
Nuitka:WARNING:     Complex topic! More information can be found at https://nuitka.net/info/debian-dist-packages.html
Nuitka-Plugins:INFO: anti-bloat: Not including 'json' automatically in order to avoid bloat, but this may cause: may slow down by using fallback implementation.
Nuitka:INFO: Completed Python level compilation and optimization.
Nuitka:INFO: Generating source code for C backend compiler.
Nuitka:INFO: Running data composer tool for optimal constant value handling.
Nuitka:INFO: Running C compilation via Scons.
Nuitka-Scons:INFO: Backend C compiler: gcc (gcc).
Nuitka-Scons:INFO: Backend linking program with 477 files (no progress information available for this stage).
Nuitka-Scons:WARNING: You are not using ccache, re-compilation of identical code will be slower than necessary. Use your OS package manager to install it.
Nuitka-Plugins:INFO: data-files: Included data file 'certifi/cacert.pem' due to package data for 'certifi'.
Nuitka-Plugins:INFO: data-files: Included 602 data files due to package data directory '.' for 'tzdata.zoneinfo'.
Nuitka:INFO: Keeping build directory '/home/leo/Github/RenderStudioKit/Build/nuitka/RenderStudioWorkspace.build'.
Nuitka:INFO: Successfully created '/home/leo/Github/RenderStudioKit/Build/nuitka/RenderStudioWorkspace.dist/RenderStudioWorkspace.bin'.
[  3%] Built target ExecuteNuitka
[  4%] Building CXX object Sources/External/fmt/CMakeFiles/fmt.dir/src/format.cc.o
[  6%] Building CXX object Sources/External/fmt/CMakeFiles/fmt.dir/src/os.cc.o
[  8%] Linking CXX static library libfmt.a
[  8%] Built target fmt
[  9%] Building CXX object Sources/Logger/CMakeFiles/RenderStudioLogger.dir/Logger.cpp.o
[ 11%] Linking CXX static library libRenderStudioLogger.a
[ 11%] Built target RenderStudioLogger
[ 13%] Building C object Sources/External/zip/CMakeFiles/zip.dir/src/zip.c.o
In file included from /home/leo/Github/RenderStudioKit/Sources/External/zip/src/zip.c:39:
/home/leo/Github/RenderStudioKit/Sources/External/zip/src/miniz.h:5090:9: note: ‘#pragma message: Using fopen, ftello, fseeko, stat() etc. path for file I/O - this path may not support large files.’
5090 | #pragma message(
|         ^~~~~~~
[ 14%] Linking C static library libzip.a
/usr/bin/ar qc libzip.a CMakeFiles/zip.dir/src/zip.c.o
/usr/bin/ranlib libzip.a
[ 14%] Built target zip
[ 16%] Building CXX object Sources/Utils/CMakeFiles/RenderStudioUtils.dir/BackgroundTask.cpp.o
[ 18%] Building CXX object Sources/Utils/CMakeFiles/RenderStudioUtils.dir/FileUtils.cpp.o
[ 19%] Building CXX object Sources/Utils/CMakeFiles/RenderStudioUtils.dir/ProcessUtils.cpp.o
[ 21%] Building CXX object Sources/Utils/CMakeFiles/RenderStudioUtils.dir/Uuid.cpp.o
[ 22%] Linking CXX static library libRenderStudioUtils.a
[ 22%] Built target RenderStudioUtils
[ 24%] Building CXX object Sources/Notice/CMakeFiles/RenderStudioNotice.dir/Notice.cpp.o
[ 26%] Linking CXX shared library libRenderStudioNotice.so
[ 26%] Built target RenderStudioNotice
[ 27%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriCommon.c.o
[ 29%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriCompare.c.o
[ 31%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriEscape.c.o
[ 32%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriFile.c.o
[ 34%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriIp4Base.c.o
[ 36%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriIp4.c.o
[ 37%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriMemory.c.o
[ 39%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriNormalizeBase.c.o
[ 40%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriNormalize.c.o
[ 42%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriParseBase.c.o
[ 44%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriParse.c.o
[ 45%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriQuery.c.o
[ 47%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriRecompose.c.o
[ 49%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriResolve.c.o
[ 50%] Building C object Sources/External/uriparser/CMakeFiles/uriparser.dir/src/UriShorten.c.o
[ 52%] Linking C static library liburiparser.a
[ 52%] Built target uriparser
[ 54%] Building CXX object Sources/Networking/CMakeFiles/RenderStudioNetworking.dir/LocalStorageApi.cpp.o
[ 55%] Building CXX object Sources/Networking/CMakeFiles/RenderStudioNetworking.dir/MaterialLibraryApi.cpp.o
[ 57%] Building CXX object Sources/Networking/CMakeFiles/RenderStudioNetworking.dir/RestClient.cpp.o
[ 59%] Building CXX object Sources/Networking/CMakeFiles/RenderStudioNetworking.dir/Url.cpp.o
[ 60%] Building CXX object Sources/Networking/CMakeFiles/RenderStudioNetworking.dir/WebsocketClient.cpp.o
[ 62%] Building CXX object Sources/Networking/CMakeFiles/RenderStudioNetworking.dir/WebsocketServer.cpp.o
[ 63%] Building CXX object Sources/Networking/CMakeFiles/RenderStudioNetworking.dir/Workspace.cpp.o
[ 65%] Linking CXX static library libRenderStudioNetworking.a
[ 65%] Built target RenderStudioNetworking
[ 67%] Building CXX object Sources/Schema/CMakeFiles/RenderStudioSchema.dir/AiTools.cpp.o
In file included from /usr/include/c++/11/ext/hash_set:60,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/hashset.h:39,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/token.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/staticTokens.h:81,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/timeCode.h:31,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/common.h:36,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/stage.h:31,
from /home/leo/Github/RenderStudioKit/Sources/Schema/AiTools.h:18,
from /home/leo/Github/RenderStudioKit/Sources/Schema/AiTools.cpp:15:
/usr/include/c++/11/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
32 | #warning
|  ^~~~~~~
In file included from /home/leo/Github/OpenUSD/Install/include/pxr/base/work/dispatcher.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/sdf/layer.h:46,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/pcp/types.h:30,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/pcp/node.h:29,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/editTarget.h:31,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/stage.h:32,
from /home/leo/Github/RenderStudioKit/Sources/Schema/AiTools.h:18,
from /home/leo/Github/RenderStudioKit/Sources/Schema/AiTools.cpp:15:
/home/leo/Github/OpenUSD/Install/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.")
|                                                                                ^
[ 68%] Building CXX object Sources/Schema/CMakeFiles/RenderStudioSchema.dir/renderStudioAiPrimAPI.cpp.o
In file included from /usr/include/c++/11/ext/hash_set:60,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/hashset.h:39,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/token.h:37,
from /home/leo/Github/RenderStudioKit/Sources/Schema/././tokens.h:40,
from /home/leo/Github/RenderStudioKit/Sources/Schema/./renderStudioAiPrimAPI.h:30,
from /home/leo/Github/RenderStudioKit/Sources/Schema/renderStudioAiPrimAPI.cpp:24:
/usr/include/c++/11/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
32 | #warning
|  ^~~~~~~
In file included from /home/leo/Github/OpenUSD/Install/include/pxr/base/work/dispatcher.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/sdf/layer.h:46,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/schemaRegistry.h:31,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/primDefinition.h:29,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/primData.h:33,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/object.h:32,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/prim.h:32,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/schemaBase.h:29,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/apiSchemaBase.h:31,
from /home/leo/Github/RenderStudioKit/Sources/Schema/./renderStudioAiPrimAPI.h:38,
from /home/leo/Github/RenderStudioKit/Sources/Schema/renderStudioAiPrimAPI.cpp:24:
/home/leo/Github/OpenUSD/Install/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.")
|                                                                                ^
[ 70%] Building CXX object Sources/Schema/CMakeFiles/RenderStudioSchema.dir/tokens.cpp.o
In file included from /usr/include/c++/11/ext/hash_set:60,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/hashset.h:39,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/token.h:37,
from /home/leo/Github/RenderStudioKit/Sources/Schema/./tokens.h:40,
from /home/leo/Github/RenderStudioKit/Sources/Schema/tokens.cpp:24:
/usr/include/c++/11/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
32 | #warning
|  ^~~~~~~
[ 72%] Building CXX object Sources/Schema/CMakeFiles/RenderStudioSchema.dir/wrapRenderStudioAiPrimAPI.cpp.o
In file included from /usr/include/c++/11/ext/hash_set:60,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/hashset.h:39,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/token.h:37,
from /home/leo/Github/RenderStudioKit/Sources/Schema/././tokens.h:40,
from /home/leo/Github/RenderStudioKit/Sources/Schema/./renderStudioAiPrimAPI.h:30,
from /home/leo/Github/RenderStudioKit/Sources/Schema/wrapRenderStudioAiPrimAPI.cpp:26:
/usr/include/c++/11/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
32 | #warning
|  ^~~~~~~
In file included from /home/leo/Github/OpenUSD/Install/include/pxr/base/work/dispatcher.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/sdf/layer.h:46,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/schemaRegistry.h:31,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/primDefinition.h:29,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/primData.h:33,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/object.h:32,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/prim.h:32,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/schemaBase.h:29,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/apiSchemaBase.h:31,
from /home/leo/Github/RenderStudioKit/Sources/Schema/./renderStudioAiPrimAPI.h:38,
from /home/leo/Github/RenderStudioKit/Sources/Schema/wrapRenderStudioAiPrimAPI.cpp:26:
/home/leo/Github/OpenUSD/Install/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.")
|                                                                                ^
[ 73%] Building CXX object Sources/Schema/CMakeFiles/RenderStudioSchema.dir/wrapTokens.cpp.o
In file included from /usr/include/c++/11/ext/hash_set:60,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/hashset.h:39,
from /home/leo/Github/OpenUSD/Install/include/pxr/base/tf/token.h:37,
from /home/leo/Github/RenderStudioKit/Sources/Schema/./tokens.h:40,
from /home/leo/Github/RenderStudioKit/Sources/Schema/wrapTokens.cpp:25:
/usr/include/c++/11/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
32 | #warning
|  ^~~~~~~
[ 75%] Linking CXX shared library libRenderStudioSchema.so
[ 75%] Built target RenderStudioSchema
[ 77%] Building CXX object Sources/Serialization/CMakeFiles/RenderStudioSerialization.dir/Api.cpp.o
In file included from /home/leo/Github/OpenUSD/Install/include/pxr/base/work/dispatcher.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/sdf/layer.h:46,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/pcp/types.h:30,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/pcp/node.h:29,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/editTarget.h:31,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/stage.h:32,
from /home/leo/Github/RenderStudioKit/Sources/Serialization/Api.h:29,
from /home/leo/Github/RenderStudioKit/Sources/Serialization/Api.cpp:15:
/home/leo/Github/OpenUSD/Install/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.")
|                                                                                ^
[ 78%] Building CXX object Sources/Serialization/CMakeFiles/RenderStudioSerialization.dir/Serialization.cpp.o
In file included from /home/leo/Github/OpenUSD/Install/include/pxr/base/work/dispatcher.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/sdf/layer.h:46,
from /home/leo/Github/RenderStudioKit/Sources/Serialization/Serialization.h:20,
from /home/leo/Github/RenderStudioKit/Sources/Serialization/Serialization.cpp:15:
/home/leo/Github/OpenUSD/Install/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.")
|                                                                                ^
[ 80%] Linking CXX static library libRenderStudioSerialization.a
[ 80%] Built target RenderStudioSerialization
[ 81%] Building CXX object Sources/Resolver/CMakeFiles/RenderStudioResolver.dir/Asset.cpp.o
In file included from /home/leo/Github/OpenUSD/Install/include/pxr/base/work/dispatcher.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/sdf/layer.h:46,
from /home/leo/Github/RenderStudioKit/Sources/Resolver/FileFormat.h:23,
from /home/leo/Github/RenderStudioKit/Sources/Resolver/Resolver.h:26,
from /home/leo/Github/RenderStudioKit/Sources/Resolver/Asset.cpp:17:
/home/leo/Github/OpenUSD/Install/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.")
|                                                                                ^
[ 83%] Building CXX object Sources/Resolver/CMakeFiles/RenderStudioResolver.dir/Data.cpp.o
In file included from /home/leo/Github/OpenUSD/Install/include/pxr/base/work/dispatcher.h:37,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/sdf/layer.h:46,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/pcp/types.h:30,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/pcp/node.h:29,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/editTarget.h:31,
from /home/leo/Github/OpenUSD/Install/include/pxr/usd/usd/stage.h:32,
from /home/leo/Github/RenderStudioKit/Sources/Resolver/Data.h:27,
from /home/leo/Github/RenderStudioKit/Sources/Resolver/Data.cpp:15:
/home/leo/Github/OpenUSD/Install/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.’
21 | #pragma message("TBB Warning: tbb/task.h is deprecated. For details, please see Deprecated Features appendix in the TBB reference manual.")
|                                                                                ^
/home/leo/Github/RenderStudioKit/Sources/Resolver/Data.cpp: In member function ‘void pxrInternal_v0_23__pxrReserved_::RenderStudioData::ProcessRemoteUpdates(pxrInternal_v0_23__pxrReserved__::SdfLayerHandle&)’:
/home/leo/Github/RenderStudioKit/Sources/Resolver/Data.cpp:183:51: error: loop variable ‘delta’ of type ‘const std::pair<pxrInternal_v0_23__pxrReserved__::SdfPath, pxrInternal_v0_23__pxrReserved__::RenderStudioData::SpecData>&’ binds to a temporary constructed from type ‘std::pair<const pxrInternal_v0_23__pxrReserved_::SdfPath, pxrInternal_v0_23__pxrReserved__::RenderStudioData::SpecData>’ [-Werror=range-loop-construct]
183 |         for (const std::pair<SdfPath, SpecData>& delta : deltas)
|                                                   ^~~~~
/home/leo/Github/RenderStudioKit/Sources/Resolver/Data.cpp:183:51: note: use non-reference type ‘const std::pair<pxrInternal_v0_23__pxrReserved::SdfPath, pxrInternal_v0_23__pxrReserved__::RenderStudioData::SpecData>’ to make the copy explicit or ‘const std::pair<const pxrInternal_v0_23__pxrReserved_::SdfPath, pxrInternal_v0_23__pxrReserved__::RenderStudioData::_SpecData>&’ to prevent copying
cc1plus: all warnings being treated as errors
gmake[2]: *** [Sources/Resolver/CMakeFiles/RenderStudioResolver.dir/build.make:90: Sources/Resolver/CMakeFiles/RenderStudioResolver.dir/Data.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:631: Sources/Resolver/CMakeFiles/RenderStudioResolver.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2


Compiling on Linux

Hi @BenPyton, cool project!
The readme says for Mac/Linux I should "Clone the repo and build the project." but there are no build system files I could find that are not for Visual Studio (OsciView.sln) but CMake, Meson, Makefile or something. Assuming there is no such thing, if I succeed in making a small CMake based build system for this project, would a pull request adding that plus a small CI based on GitHub Actions to catch future build breakage be welcome?
Best, Sebastian

Hi hartwork,
Of course a pull request is welcomed :)
I've always preferred CMake because of cross platform, but for my personal projects like this one I use Visual Studio so I can start coding in one click.
For CI however I've never used github actions... What do you plan to do with it? Is there any restrictions, like having a server hosted elsewhere?
In all cases, you create separate pull request for each, and discuss that at this time :)
Also, it is not related to your question, but I need to check on my computer, I remember that I changed some little things for the FFT computation. I used a third party code to improve greatly the performances.
Best regards.

Hi hartwork,
Of course a pull request is welcomed :)

@BenPyton cool!

For CI however I've never used github actions... What do you plan to do with it? Is there any restrictions, like having a server hosted elsewhere?

Good question, let me say a few words on that. GitHub Actions is free for all public repositories like this one. We add one or more YAML files to a specific folder in Git to tell it what to do and then it will run some code for every Git push, every change to a pull request, or periodically like once a week. The key idea is to ensure that the code not only builds without errors today but also that whenever e.g. a pull requests is going to break the build in the future it will not go unnoticed but be caught by GitHub Actions.
To see that in action elsewhere, I have a pull request https://github.com/JanKleprlik/AudioVisualiser/pull/3 where I'm contributing something very close to what I'm envisioning us to do here. The past runs from that case can be inspected at https://github.com/hartwork/AudioVisualiser/actions if you like. Happy to answer questions on CI and GitHub Actions.
What do you think?

In all cases, you create separate pull request for each, and discuss that at this time :)

I would prefer to keep them combined because the CI will be the test that what I did in the build system works in practice, not just on my machine. Let me demo the combined version (with separate commits) and we can extract things from there before merging as needed, if I didn't mange to convince you by that time.
What do you think?

Also, it is not related to your question, but I need to check on my computer, I remember that I changed some little things for the FFT computation. I used a third party code to improve greatly the performances.

Sounds good!

Okay!
I'm curious of how it works :)

@BenPyton glad to hear! Take your time to look around and/or play with it if you like, happy to answer questions.


Can't edit transmission settings.json

When I edit the settings.json in my TRANSMISSION_FILES_ROOT and restart the daemon the settings file just gets overwritten by the default file.
Is there any way I can maybe just edit the default settings.json that gets recopied there?

You have to stop the daemon before editing. Transmission overwrites the settings file when it shuts down.

Sadly I can't confirm this behavior

Ah nevermind it just automatically seems to reorder settings lines as well, thanks


Fix the carousel view not displaying hero block. Also enabled Welcome…

… images to be selected.

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


NIFI-8659: Support multiple output records in JoltTransformRecord

Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
Adds support for a single input record being transformed into multiple output records in JoltTransformRecord. Also replaced the inefficient stream() commands in the normalize() methods to for-loops for a performance boost.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically main)?

[x] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[x] Have you verified that the full build is successful on JDK 8?
[ ] Have you verified that the full build is successful on JDK 11?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

Thanks @mattyb149 all looks good to me now. Have tested and all works as expected. +1 merged to main!


Voice list and bug fix

fixed issue with voice array disappearing after window.reload()
changed lang to include country eg en-US compatible syntax with Chrome's Web Speech API
For lollipop onwards, returns a complete list of actual voices using mTts.getVoices() and stores in Set voiceList
For older android we enumerate all locales using mTts.isLanguageAvailable()
Enables specifying voice using voiceURI or setting object as per spec (previously only used lang setting)

@mike-nelson thanks for this. Sorry it took so long to merge. Sometimes life gets in the way.


Update bio tagging user

When updating the account's bio of an account tagging a user (like @/instagram) it doesn't make it available to click and only shows it as a string.
The method used for updating the bio is: account_edit

@dmunozv04 thanks! I'll take a look this week

Why use " @/ "  in tagging? Just write the username, you do not need " / ".

When tagging on Instagram I didn't use the /. I used it on GitHub so that it wouldn't ping that user. I'm sorry for not making that clear

When tagging on Instagram I didn't use the /. I used it on GitHub so that it wouldn't ping that user. I'm sorry for not making that clear

I tried this and it worked properly, no problem!
cl.account_edit(biography="@instagram")

and for multi tagging you can use "\n" like this:
cl.account_edit(biography="@instagram\n@test1\n@test2")

@zankoAn in the web-browser the links are clickable, but in the Instagram application they are not
I think @dmunozv04 talked about this problem

Exactly, the people tagged are not clickable on the Instagram apps when using the account_edit option but they were when I sent requests with Charles Proxy

@dmunozv04 implemented in instagrapi 1.9.7

Thank you!


adding validateWithFields() to support consuming fields in a validator

in #690 the validate() signature was updated to support consumption of fields: Fields, but this change also made it a required parameter of generated validator function. This PR effectively reverts #690 and creates a new validateWithFields() wrapper that exposes the generated validator from validate() with a signature that supports consuming the fields param.

I'm running into further issues with testing this. I'm going to look into this a bit deeper.

yea i though about the const approach but scrunched my nose at it 😄


Clean up messages

Consolidated all commands in commons.core.Messages
Improve messages (wording and alignments/indentations) to make feedback to user look more readable
Fixed minor nits

Resolves #121

Codecov Report

Merging #139 into master will decrease coverage by 0.26%.
The diff coverage is 90.00%.

@@             Coverage Diff              @@
##             master     #139      +/-   ##
============================================
- Coverage     74.62%   74.36%   -0.27%
- Complexity      534      535       +1
============================================
  Files            90       90
  Lines          1616     1619       +3
  Branches        165      167       +2
============================================
- Hits           1206     1204       -2
- Misses          332      336       +4
- Partials         78       79       +1

Impacted Files
Coverage Δ
Complexity Δ

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)
0.00 <0.00> (ø)

...java/seedu/address/logic/commands/ExitCommand.java
100.00% <ø> (ø)
2.00 <0.00> (ø)

...java/seedu/address/logic/commands/HelpCommand.java
100.00% <ø> (ø)
2.00 <0.00> (ø)

.../seedu/address/logic/commands/RequiredCommand.java
97.22% <ø> (ø)
22.00 <0.00> (ø)

.../java/seedu/address/logic/commands/YesCommand.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)
1.00 <0.00> (ø)

...rc/main/java/seedu/address/logic/LogicManager.java
38.63% <25.00%> (+0.54%)
5.00 <0.00> (ø)

...in/java/seedu/address/logic/parser/ParserUtil.java
90.32% <75.00%> (ø)
11.00 <0.00> (ø)

.../java/seedu/address/logic/commands/AddCommand.java
100.00% <100.00%> (ø)
7.00 <0.00> (-1.00)

...a/seedu/address/logic/commands/CheckMcCommand.java
100.00% <100.00%> (ø)
3.00 <0.00> (ø)

... and 26 more

Continue to review full report at Codecov.

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


[graphiql] unclear how directives like @includes or @cascade can be added to a query

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
when hitting the @-Symbol on the keyboard the editor enters a Go-to-line input-field instead of placing the character.
This makes it impossible to enter directives interactively.
Expected Behavior
When hitting the @-Symbol on the keyboard the editor should display the @-Symbol, so 2.12 directives can be added interactively.
Steps To Reproduce
1. hit `@` on the keyboard
2. be unable to add directive

Module pattern

[ ] graphiql-umd
[ ] graphiql-esm
[ ] graphiql-commonjs

Environment
- GraphiQL Version: 2.2.0
- OS: MacOS
- Browser: Chrome 109
- Bundler: [CDN bundle](https://github.com/graphql/graphiql/blob/main/examples/graphiql-cdn/index.html)
- `react` Version: CDN bundle
- `graphql` Version: CDN bundle

Anything else?
Thank you for providing the bundles.

This used to work better - the autocomplete is designed to work here and works in monaco and vscode/LSP - @thomasheyenbrock do we know what happened here? perhaps a codemirror release introduced the @ behavior and we need to disable it?

huh, i can't seem to re-create this bug. can you supply a codesandbox that re-creates this if it's still an issue?

the other issue may be that your schema's introspection query response is not including directives, or your schema value does not include directives.


Refactor TDAG-format, differentiate taint sources

Decide on a more appropriate abstraction for taint sources. Currently it is file-focused, e.g. the file descriptor is stored along side. However, with the introduction of argv tainting this abstraction no longer holds. Also, additional taint sources are being planned for e.g. sockets.
This will require a refactor of the TDAG file (at least slightly).
I believe we should plan for implementing the 'Section'-type previously discussed, and use a shared string table.

#6500 implements the section handling.


Misc. add to region enhancements

When adding a cortical area to a region:

rename the window title to "Select a Target Brain Region"

in the case there is no subregion available, directly launch create new region window

rename "add region" button to "Create Brain Region"

When displaying the candidates to user for adding to a region, do not show the ones already added

Enable user to select multiple areas at the same time when adding. (need to address multi select holistically)

rename "Select object from genome" to "Select Candidates"

Current redesign handles added these improvements


Build Documentation Locally

Hi,
Is there a tool for building your documentation locally?  I would like to add the mjml documentation to the user contributed docs for the documentation browser Dash.

Hey Josh,
Nice, thanks :-). For now the website documentation is not on Github, would it work if I provide you with the static version of the doc or do you need to be able to automatically build it so it can be automatically updated?

For now, a static version of the doc will help me get it up on Dash.
For a few other docsets that I maintain for Dash, I just watch for new releases via rss, and then build the docs locally > push to Dash.  What we do ongoing is up to you really, Ideally I'd like it to require no manual action on your end, but at the same time if there's a burden in setting it up initially, it might be better the other way!

Alright as a start I can give you a static version. We should update the website next Tuesday to support MJML v3 and the doc will be up to date, can I share it with you once this is done?

Of course.
On 4 November 2016 at 11:41, Nicolas Garnier<EMAIL_ADDRESS>wrote:

Alright as a start I can give you a static version. We should update the
website next Tuesday to support MJML v3 and the doc will be up to date, can
I share it with you once this is done?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mjmlio/mjml/issues/436#issuecomment-258483177, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQb_Xys6Z3VBc4bn3wpC6wlJhhyMsNd3ks5q62AcgaJpZM4KobHw
.

hey @jaypeedevlin, can you please send me an email to<EMAIL_ADDRESS>so we can discuss about what you need and I can share a static version with you?

Sure.


Ambiguity on KeyUsage with ECC public key

This issue was discussed in GoogleGroups and Bugzilla as follows:
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/ito|sort:date/mozilla.dev.security.policy/vDhKG7T6sCM/gKwMGqrYAwAJ
https://bugzilla.mozilla.org/show_bug.cgi?id=1560234
If the KeyUsage of the certificate with ECC public key contains both digital signature and key encryption, cablint returns as the error when we run cablint.
However, current zlint does not return as the error.
If zlint can return as the error, I think zlint will be a better tool.

:wave: Thanks for opening an issue about this @jinNakamura. I spent a little bit of time reading the MDSP, LAMPS/SPASM, and Bugzilla discussion and I think I'm up to speed now.

If zlint can return as the error, I think zlint will be a better tool.

My understanding of the discussion consensus is that while this EKU/public key algorithm combination is non-sense it isn't clearly forbidden by the relevant RFCs/BRs as they are written today. Based on that conclusion there could be an argument made that a lint for this condition should return a Warn level lint finding and not an Error level finding until the RFC 5480 key usage clarification draft is finalized.
Personally I'm not opposed to implementing a lint at the Error level (matching cablint) ahead of that clarification being finalized but I wanted to call this out specifically so that other zlint community members/relying users could weigh in.

@cpu I agree with your assessment. Unfortunately, there are a number of places in the RFCs and BRs where the ambiguity of the term "MAY" is left up to the interpretation of the CABF and not clearly defined in the documentation. This was also the case with a previous PR that was rejected.
One of the difficult aspects of just flat out re-implementing cablint and x509lint functionality into zlint is that both of those linters have baked in "interpretation-level" errors and warnings. With the current ambiguity, I would argue that Notice level would be more appropriate, but I could be convinced toward Warn only because draft RFC 5480 could fix this ambiguity when finalized (at which point, Error would indeed make the most sense).
My main concern with making a resulting lint Error level right now would be that it sets an odd precedent for interpreting ambiguous rules that are only clearly defined in conversations that are easily lost to the winds of time after a few months on MDSP and Bugzilla. These platforms are great for discussion but there shouldn't be hidden compliance gremlins that can only be historically gleaned from those sources baked into zlint as opposed to the written rules codified in the RFCs and BRs.

@cardonator These are good points, thanks. You've convinced me that avoiding Error level for the time being is prudent since it would be easy to ratchet to that level in the future.

With the current ambiguity, I would argue that Notice level would be more appropriate, but I could be convinced toward Warn only because draft RFC 5480 could fix this ambiguity when finalized (at which point, Error would indeed make the most sense).

I'm fairly fuzzy on what the distinction is meant to be between Notice and Warn, is there a reason you favour the one of the other in this case?
One of my takeaway's from thinking about this issue is that it would be nice to capture some of this thought process into documentation somewhere. The docs for adding new lints in the README are fairly mechanical in nature and don't address the "spirit" of zlint or its lint result levels.

@cpu based on our use case with zlint, we use Notices to log informational only lints during the issuance process, but they don't impact issuing the certs at all. When we get a Warning, the lint message has to be reviewed prior to issuance. When we get an Error, we alert and block issuance.

I haven't had a chance to look at this issue in depth, but I wanted to provide some historical context on the lint levels. We originally defined four levels with specific definitions.
Error: Violation of RFC/BR MAY or MAY NOT type of statements. Certificate unequivocally does not conform to standard. Each lint must have a specific statement like that in its citation.
Warn: Violation of RFC/BR SHOULD or SHOULD NOT type statement. Again, there needs to be a specific citation, but it's not a misissuance based on this.
Notice: FYI types of statements or violations of non-codified community standards. We're much more lax about what goes here. These need to follow common sense, but do not need to be in the RFC or BR. In one case (presence of CN), we downgrade warn to notice.
Fatal: Something is wrong with the certificate such that we can't run the appropriate check.

@zakird Thanks for the historical context. Out of curiosity, did you mean to say MUST and MUST NOT as part of the definition of an Error type? IMO much of the ambiguity comes from MAY and MAY NOT which don't necessarily imply that the opposite behavior is disallowed by the BRs/RFCs. This ambiguity was highlighted by Ryan in the referenced conversation:

If I understand this question correctly, it's asking about whether the MAY
of values (X, Y, Z) means SHALL NOT/MUST NOT for values (A, B, C).
One interpretation says "You may set these values... or any other value".
The MAY tells clients what they should be prepared for, potentially
allowing them to reject any value outside of that if they're unprepared for
it.
Another interpretation says "These are the ONLY values that MAY be present.
You MAY assert one or more of them, but you MUST NOT assert something else"
While I have thoughts on "what is sensible", I'm not sure if that's aligned
with "what is required"

🤦♂ You're absolutely correct. MUST/MUST NOT not MAY/MAY NOT May/May not would be warnings.

Thank you for your comments.
As you said, the RFC has not been officially updated yet.
Therefore, we also thought that the Warn level is appropriate at this stage.
Also, if the RFC is officially updated, we will let you know the information again.

@zakird Thank you for the added historical context on the lint levels. That was really useful to read :+1:  I think your description of Notice matches up well with @cardonator's rationale/preference for this specific situation.
Unless someone else is more eager than me I'll work on banging out a quick lint for this at the Notice level in the next ~week.

Also, if the RFC is officially updated, we will let you know the information again.

Thanks @jinNakamura, that would be great.

Unless someone else is more eager than me I'll work on banging out a quick lint for this at the Notice level in the next ~week.

Here's a PR: https://github.com/zmap/zlint/pull/293 I'd appreciate :mag:'s and :eyes:'s when folks are free. Thanks!

Resolved in master by d9a29c3 :tada:

Updating the issue with the final RFC that clarifies Elliptic Curve Cryptography Subject Public Key Information and Key Usage bits.

https://datatracker.ietf.org/doc/html/rfc8813


2.3.7

Using updated lazy-cache and adding .unlazy method to main export to allow loading all dependencies immediately.
var mm = require('micromatch').unlazy();

This will fix #52 in nyc when updated.

closing since @doowb and I discussed a better solution


Add a -name flag to set the global span name

This is already fixed via https://github.com/rakyll/go-test-trace/commit/1b935af706ef63c0d690eeab6108fefe5716b708.


CDPSDX-3491: Modified use of stack name for stack termination and status checking when the stack is detached to avoid multiple issues.

Jira: https://jira.cloudera.com/browse/CDPSDX-3491
Main issue here is that for certain cloud providers (specifically Azure and the Mock Cloud Provider), in some cases the stack name is used to define important resources.
For Azure this includes the name of the resource group created where the stack instances are located (this is only for cases where the environment is created without a pre-specified resource group).
It's very clear that after a detach, when the stack name is modified, these resources will no longer be able to be located resulting in errors.
Specifically, we see errors in two places:

The StackStatusCheckerJob as it attempts to verify the health of the stack instances using an incorrect resource name
The termination of the stack, where it attempts to terminate the stack and its instances using an incorrect resource name

My main goal with this work was to provide a way for the 2 cases above to use the original stack name, instead of the detached one. I hope it is clear how this fixes the issue.
As such, my changes consist of the following:

Adding a new originalName field to the stack object
During updating of the stack name/crn, I now update the originalName field and ensure the field is what we expect if the stack is being detached
Use a new retainOriginalName field in the updateNameAndCrn method to track if we want to store the original name or set it to null

That's literally all I changed. I unfortunately have not been able to test this yet, but am doing so now. However, as this is a pretty important issue, I would appreciate as many eyes on it as possible.

Apparently Mock provider uses Stack CRN instead of stack name for whatever reason, so I modified that too.
One other thing I could do if anyone thinks this is too intrusive, is introduce new fields in the CloudContext object. I could then use those specifically in the specific actions which have issues.
However I have looked through the code and do not see any alarming places where this may be an issue.

Giving up on fixing Mock, see Jira for issues. Azure is more important and easier to fix.

I have finished verifying that this works as desired.

Made a few changes:

Instead of a new detached boolean field, Stack now has an originalName field
When the stack is detached, originalName is the first name the stack had, otherwise this field is null
CloudContext now has an originalName field as well which is only used in the problematic case I discovered

I hope that these changes make this a lot cleaner and apparent.

Small update:

Renamed the detached field to retainOriginalName field in order to keep the stack update method agnostic to the resize process.

I have now pointed this at being merged into the master branch. Please merge it in as soon as possible so we can start testing with it.

Pointed this at 2.56.0 instead of master.


/www/js/config.js

Is /www/js/config.js used by the app?
N.B. Its not mentioned in the text of the book.

No.  We initially used the Yeoman Ionic Generator to create the app.   It needs to be removed.

Ahh, the generator authored by Diego.
Thanks.

Correct.  Some of the early feedback we got was to use gulp instead of grunt so we decided to just use the Ionic gulp base.  Most of the team uses the generator for new projects because it offers quite a few benefits.

To remove the config module In app.js you just need to:

remove the reference to 'config'
.run(function($rootScope, $ionicPlatform) {  // .run(function($rootScope, $ionicPlatform, ENV)
// console.log('Environment:', ENV.name);

BTW, it would be good if you could add comments like https://github.com/johnpapa/angular-styleguide#style-y165
angular.module('Trendicity', [
// see /www/js
'config',
// see /www/lib
'ionic',
'ionic.contrib.ui.tinderCards',
'ionic.contrib.icon',
'LocalStorageModule',
'ngCordova',
'http-auth-interceptor',
'uiGmapgoogle-maps'
])

I forgot.   The app is using the ENV hash.


Support parsing leading decimal dot for minified obj files

I recently tried to reduce the file size of my game and came across a tool to minify obj files:
https://compress-or-die.com/obj
One used method is to remove redundant information from decimal numbers by for example changing -0.730000 to -.73.
Unfortunately tinyobjloader does not support parsing decimals with a leading decimal dot such as .73 or -.73 so it would be cool if this could be supported if it's not too much work.

Parsing floating point value is all handled in tryParseDouble
https://github.com/syoyo/tinyobjloader/blob/master/tiny_obj_loader.h#L567
It should be rather easy to adding support for parsing .73 by tweaking this function. PR is always weldome!


feat(provenane): add provenance through publish config

Current dependencies on/for this PR:

main

PR #101   👈

This comment was auto-generated by Graphite.


ImportError: DLL load failed: %1 is not a valid Win32 application.

While compiling the SquareToCircle and WriteStuff Demos, I get this %1 !

I uninstalled Python 32 and got the 64 bit one , but now its not recognizing the "color" ....Please help!


Add retry logic for failed HTTP requests

The HTTP client will retry 3 times in case of connection or server errors. It will also honour Retry-After headers sent with HTTP 429 and 503 status codes. Client errors, such as all 400 code responses apart from 429, will not be retried.
This closes cessda/cessda.cdc.versions#529.

Tests still need to be implemented

Test implemented, the PR is ready for review


macos-13 job crashes without logs

Description
macos-13 job crashes after (roughly) 30 minutes, without logs
Platforms affected

[ ] Azure DevOps
[X] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
Image: macos-13
Version: 20230419.1
https://github.com/lima-vm/lima/actions/runs/4799814791/jobs/8596609974?pr=1511
Is it regression?
Yes (macos-12 → macos-13)
Expected behavior
Should not crash without logs
Actual behavior
Crashes after (roughly) 30 minutes without logs

Repro steps
Run a job with macos-13 runner

interesting. I'll have a look

@AkihiroSuda , I tried to run in my fork
seems, it awaits for
time="2023-04-28T12:37:24Z" level=info msg="[hostagent] 2023/04/28 12:37:24 tcpproxy: for incoming conn <IP_ADDRESS>:49278, error dialing \"<IP_ADDRESS>:22\": connect tcp <IP_ADDRESS>:22: no route to host"
time="2023-04-28T12:37:34Z" level=info msg="[hostagent] Waiting for the essential requirement 1 of 3: \"ssh\""
time="2023-04-28T12:37:37Z" level=info msg="[hostagent] 2023/04/28 12:37:37 tcpproxy: for incoming conn <IP_ADDRESS>:49279, error dialing \"<IP_ADDRESS>:22\": connect tcp <IP_ADDRESS>:22: no route to host"
time="2023-04-28T12:37:47Z" level=info msg="[hostagent] Waiting for the essential requirement 1 of 3: \"ssh\""
time="2023-04-28T12:37:51Z" level=info msg="[hostagent] 2023/04/28 12:37:51 tcpproxy: for incoming conn <IP_ADDRESS>:49280, error dialing \"<IP_ADDRESS>:22\": connect tcp <IP_ADDRESS>:22: no route to host"

what's that ? how that routing is supposed to appear ? where it tries to connect to ? is it some qemu vm started on runner ?

@ilia-shipitsin Thanks for testing.

How did you get that log? Is that timeout relevant to the 30-min timeout of the GHA job?
<IP_ADDRESS> is a virtual IP that is not accessible from the host. Equivalent of <IP_ADDRESS> of QEMU and Virtualbox.
Lima uses a Unix socket to dial that virtual IP, but it looks like the virtual network stack is somehow not functional.
I'm not sure whether that virtual network failure is relevant to the 30-min timeout of the GHA job.
The "vz" mode uses Apple's Virtualization.framework, not QEMU.

I cloned your repo, removed all build definitions except "vz".
30 min, I guess, defined here ...

AFAICS that's the timeout of the step, not the job?

@AkihiroSuda , I see better logs with the following invocation
    - name: Test
      run: |
        ./hack/test-example.sh examples/experimental/vz.yaml

previously I removed 30 min limit and job fails after 48 min (no logs caught)

interesting observation, when build is running, I can see logs.
when build is complete, there are no logs

@AkihiroSuda , I tried to run commands on fresh macos-13 vm
INFO[0000] Terminal is not available, proceeding without opening an editor
WARN[0000] `vmType: vz` is experimental
INFO[0000] Attempting to download the image              arch=x86_64 digest= location="https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.img"
INFO[0002] Using cache "/Users/runner/Library/Caches/lima/download/by-url-sha256/6b15519b255a45a238b7a8154cd57da120344ea388143af2821bb790af7fc587/data"
INFO[0006] Attempting to download the nerdctl archive    arch=x86_64 digest="sha256:955f9a4853762b1258cd38c967e45b6061a181a668907059e56cc01c32f1cf21" location="https://github.com/containerd/nerdctl/releases/download/v1.3.1/nerdctl-full-1.3.1-linux-amd64.tar.gz"
INFO[0006] Using cache "/Users/runner/Library/Caches/lima/download/by-url-sha256/ced4c1bbc347f1a74f9f9f25172cdb69115d21bf84000cc529013917a24a067a/data"
INFO[0006] [hostagent] Replacing "ftp_proxy" value "http://localhost:2121" with "http://<IP_ADDRESS>:2121"
INFO[0008] [hostagent] Starting VZ (hint: to watch the boot progress, see "/Users/runner/.lima/vz/serial.log")
INFO[0008] [hostagent] Setting up Rosetta share
WARN[0008] [hostagent] Unable to configure Rosetta: Rosetta is unsupported on non-ARM64 hosts

after that communication to vm was lost (no idea why).
is there a way to make limactl more verbose ?

is there a way to make limactl more verbose ?

limactl --debug may print more verbose logs.
Also, you may find some errors in ~/.lima/vz/ha.{stdout,stderr}.log.
But I'm not sure if that is relevant to my OP. (The problem is that I can't see the failure log)

yes, I agree that having logs sounds good.
as I discussed with colleagues, there are some edge conditions in Github Actions when logs are lost. It is bad, but we cannot fix it within "runner-images" repo. I'll ask what is proper way for tracking that issue

@AkihiroSuda , may I ask you to open an issue at https://support.github.com/ ?
I was told by my collegue that it is proper way for customer support.
also, I've searched for similar issues there, surprisingly, no luck
actually, we had several similar issues
https://github.com/actions/runner-images/issues/7004
https://github.com/actions/runner-images/issues/3517
https://github.com/actions/runner-images/issues/736
https://github.com/actions/runner-images/discussions/7188
https://github.com/actions/runner-images/issues/6378
https://github.com/actions/runner-images/issues/6350
all were closed as "it is something with resource consumption". I'm not sure that resource overconsumtion should lead us to logs "completely" lost. for me, it would be fine to keep at least those logs avaiable during run

@AkihiroSuda , I contacted colleguaes, they followed up escalated issue.
I'm closing this one.
feel free to reopen if needed

they followed up escalated issue.

Yes, but the issue is still unresolved AFAICS
https://support.github.com/ticket/2146507

It is not something I have an access to ((
if you think it makes sense, we can keep this issue open

Hello, @AkihiroSuda !
did you receive some update in https://support.github.com/ticket/2146507 ?
(I do not have permissions to check)

Yes, heard that logs are only available as best-effort. So I'm fine to close this issue.


Distinguish between heat & cool modes in exposed 'thermostat'

Is your feature request related to a problem? Please describe.
Currently, we expose a single 'auto' mode (heat/cool) rather than distinct modes.
Describe the solution you'd like
Explicitly separate between heat & cool modes. Then, treat the "temperature" as the relative strength of each mode. That will help with exposing the thermostat to Google, which currently doesn't know how to handle this thermostat (e.g. it seems to get confused at a negative temperature).
We might even be able to expose it as step increments starting at 50 & in increments of 5 (or something along those lines). Then, normalize it back to values that Eight natively understands.
Describe alternatives you've considered
Right now Google assistant is good enough to turn it on and off. But any adjustment of the strength seems to break it.
Additional context

it seems to get confused at a negative temperature
...

 But any adjustment of the strength seems to break it.
Could you clarify if google assistant works for negative temperatures? What queries are you making, negative temperature queries like "Set bed heat to -100 degrees" works for me.
I considered using explicitly heat vs cool mode, my main reason I did not implement it is that now the mode would change what "set bed temperature to 50 degrees" means.
The UI is also a tough problem. We could make it from 50 to 100, but really not very intuitive for the user to think on that scale.


How would you do to dispatch an action in getInitialProps?

WDYT in create a HOC to makes it possible to call a dispatch in getInitialProps?
Like this one: https://github.com/zeit/next.js/blob/master/examples/with-redux/lib/with-redux-store.js
I also have tried to insert it in _app. It dispatch the action, however for some reason it doesn't update the store, could you help me?

Hi
I think you need to some modification
https://github.com/deptno/next.js-typescript-starter-kit/blob/master/pages/_app.tsx#L32
It's wrong code 😅, you have to get Store from getInitialProps

I think it's main error point about problem you have

https://github.com/deptno/next.js-typescript-starter-kit/blob/master/pages/_app.tsx#L10

persistStore may cause error,
persistStore works async. so you MAY need to wait for persist store has done.
make async function

https://github.com/deptno/next.js-typescript-starter-kit/blob/master/src/store.ts#L38-L40

as-is
persistStore(store, {whitelist}, _ => {
  console.log(`define whitelist: ${whitelist.join(', ')}`)
 })

to-be
await new Promise(resolve => persistStore(store, {whitelist}, _ => resolve))

and use await
as-is
const store = getStore(undefined, server)

to-be
const store = await getStore(undefined, server)

https://github.com/deptno/next.js-typescript-starter-kit/blob/master/src/store.ts#11

as-is
export const getStore = (state, isServer?): Store<RootState> => {

to-be
export const getStore = async (state, isServer?): Store<RootState> => {

Can you let me know is it work?

Well... I couldn't make this works in that way.
However It works using https://github.com/kirill-konshin/next-redux-wrapper
Thanks for the work in this starter kit anyway!

ok thanks for your response
2018년 8월 24일 (금) 오후 10:37, Guilherme Lopes<EMAIL_ADDRESS>작성:

Well... I couldn't make this works in that way.
However It works using
https://github.com/kirill-konshin/next-redux-wrapper
Thanks for the work in this starter kit anyway!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/deptno/next.js-typescript-starter-kit/issues/19#issuecomment-415761272,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABKpbAlGEwNx7VC8yS9k0C9O2rI9uVnWks5uUAGwgaJpZM4WJ5m8
.

--
Sent from Gmail Mobile


Check version

I have installed v2ray on a VM with this command bash <(curl -s -L https://git.io/v2ray.sh). How can I find the installed version? Also, how can I get latest update? What are the instructions?

Run v2ray version to find the installed version.
link https://github.com/v2fly/v2ray-core/releases/latest/download/v2ray-linux-64.zip will always point to latest V2Ray binary release for Linux on amd64.
The script you are using seems to be unmaintained (original repo  was deleted).
Why not try to understand how to configure V2Ray manually and then automate it yourself?
There's also a guide on configuring V2Ray as well.

The guide you mentioned points to downloading a script named go.sh which says This script has been DISCARDED. I am a bit confused. The v2ray-linux-64.zip contains binary and config files which I think are used for manual installation. Am I right?

The guide is only a reference, something would surely be out of date. You don't have to copy every step.
Like most Go applications, V2Ray is mostly self-contained. Just unpack the archive and you are done.
If you are on a bleeding edge distro like Fedora, Arch, openSUSE, then installing V2Ray via the package manager might actually be easier.
My personal advice is that don't jump to scripts and try to figure out how to use V2Ray manually, the knowledge you gain from this process will be very helpful in building a robust proxy.

OK Thanks. I will create the next issue in the next topic.


Feature request: can we have a command summarizing what has been updated by the user?

something like:

list_my_changes

gives the list of defines I have updated with their latest value

Is it a history of the commands previously typed ?
Is it a history of the define command ?
What would be the output of list_my_changes ?
@fred-r


ZeroMQ.Proxy.dll not a valid Win32 application

Added NetZMQ via NuGet to an Any CPU project. On run, I get an exception on this line:
_publishContext = ZeroMQ.Sockets.ZmqContext.Create(1);
Could not load file or assembly 'ZeroMQ.Proxy.dll' or one of its dependencies.  is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
Looks like an awesome library so far, so trying to get this working.. :)

Hmm, interesting.
Do you have the Visual C++ 2010 Redistributable Package installed? I haven't tested this on a machine without the C runtime yet, so that may be an issue.
Also, are you running 32 or 64-bit Windows?
Thanks for testing it out!

I am running 64-bit Windows 7 with the following installed (Dev workstation):
Visual C++ 2005 Redistributable
Visual C++ 2008 Redistributable - x86 9.0.30729.4974
Visual C++ 2010 x64 Designtime - 10.0.30319
Visual C++ 2010 x64 Runtime - 10.0.30319
Visual C++ 2010 x86 Runtime - 10.0.30319
Exception occurred when running straight from Visual Studio 2010 in debug mode - haven't tested it any other way.
Let me know if you want additional info...

Another question for you: do you have any other libzmq.dll files floating around, especially in your project Output dir or on the system path?
If there are other libzmq.dlls in the search path, netzmq will use those instead of its bundled versions. This was done for flexibility, but it might end up biting a lot of people. So in your case, if you have a 32-bit libzmq somewhere, netzmq might be trying to use that even though it is running in 64-bit mode, which would cause a BadImageFormatException.
Are there any inner exceptions bundled in the exception you're seeing?

I did remove all of the libzmq references, however it's entirely possible that I missed one. I'll double check this and give it a try as well as check for InnerExceptions.
Thanks!

Brandon, were you able to get this working?


Record charged energy in kwh instead of wh

The sensor in the go-e integration is designed to give wh:

Unfortunately this does not seem to work well in the home assistant energy dashboard since it seems to expect kwh:

Is it somehow possible to make home assistant read the values correctly so that it is also correctly shown?

I just found that in the energy dashboard setting there is a warning/error hidden:

No idea if this has something to do with my issue mentioned above

Which Home Assistant version do you use? I will try to reproduce the issue with a fresh Home Assistant instance (2022.8.0) tomorrow.

Home Assistant 2022.7.5
Frontend 20220707.1 - latest

Which version of this custom component do you use?

I made some progress: It looks like you are the first one using the key wh at the energy dashboard. More common is using eto (total energy). Could you do me a favor? Please check the history of your wh sensor. Does the value reset once a day or does it increase without resets? Could you try to explain the difference between eto  (total energy)  and wh (energy charged)?
Is this assumption correct: If you charge your car 3 times a day the wh sensor increases 3 times from 0 to charged energy?

I've pushed a fix which should improve the situation (hopefully): https://github.com/syssi/homeassistant-goecharger-mqtt/commit/9274c8509e5ff5b30e6133e11867069490d18da8

I've published some fake traffic using
I=0
while true;
do
  I=$(($I+1000))
  mosquitto_pub -r -t /go-eCharger/111111/wh -m $I
  sleep 60
  echo $I
done

and checked the energy dashboard 1-2 hours later:

On my side it looks fine now. I will prepare a release now. Please update your custom component to the new version and close the issue if it's solved.

Hi! Thank you for your incredible support! :) And sorry for my late response :(
I just updated the custom component to 1.12.1 and home assistant to 2022.8.1 (which was requested due to compatibility issues).
Unfortunately the energy dashboard still does not show the charged energy amount (it seems to still get it in wh instead of kwh), although the weird warning/error message I mentioned earlier did disappear now.
Regarding eto (total energy) vs. charged energy: I can not choose any sensor named eto in the energy dashboard configuration. I also cannot tell the difference beteeen eto and charged energy, but imo only charged energy makes sense in the case of the energy dashboard (since it is only necessary to include the actually consumed power).
Loading multiple times should work, but unfortunately it seems I have lost the old charging data when I readded the charged energy sensor to the energy board.

Please take another look after a few hours at your energy dashboard. The propagation of the data just takes some time.

Awesome, it works! Thank you so much! :)


Any ideas on responsiveness?

Howdy!  Has anyone had any luck making the panels wrap responsively when moving to a mobile?  If I set the css min-width: 320px; the panels overlap on each other.  Any luck with a css that does this a little better?  Thanks!

Hi @dk253,
Checkout PR 182.  I've added the min-width feature in this PR to support such a use case.  You should see the widgets wrap to the next row when resizing the browser.
Regards,
Willet


[Docs]: Add instructions to install Tesseract for OCR

Change Requested
OCR requires Tesseract, which can be installed using HomeBrew:
brew install tesseract
Link to the relevant section of the documentation
https://github.com/chrisgrieser/shimmering-obsidian#Workflow-Installation

Instructions for installing tesseract are already included in the docs here.
I tried to keep the initial setup as easy as possible, since most users will not actually use the OCR screenshot feature.


Fix some key notebooks prior to including in CI

Objectives

Get some key notebooks working cleanly so they can be included in CI as per #39

Todos
What needs to be done for the issue to be done and the objectives to be reached:

Agent_Close_Following.ipynb - remove bUCF param in call to makeTestEnv

Minimal testing requirements
What functionality shall be covered by a test (qualitatively describe each test):

pytest --nbmake [list of notebooks]

Note this doesn't mean fix all the notebooks, just a handful that are currently relevant.


InvalidVectorPath error on pay_with_googlepay_button_content.xml

Describe the bug
lintDebug error prevent android gradle build
To Reproduce
Steps to reproduce the behavior:

Go to 'android' folder
run ./gradle clean build
error: node_modules/@stripe/stripe-react-native/android/src/main/res/drawable-bg-night/pay_with_googlepay_button_content.xml:2: Error: Use -0.009 instead of -.009 to avoid crashes on some devices [InvalidVectorPath]

Expected behavior
should build successfully

Device: macbook pro
OS: macos x86
RN version: 0.69.1
Library Version: 0.14.0

what version of Gradle are you using?

this is if u run from a RN app,
but i realise we dont need to run this gradlew clean build at all if we just want to run it in RN,
was busy debugging issues, i thought this could be one of the reason why its not working
anyway for future developers who got stuck on this path, this path is not it. the issue is somewhere else


Error Logs not working

It would appear that the server error logs are no longer working correctly.
If an error occurs, a notification will be sent to the staff users, but the error does not exist in the database:

This happens for "naturally occuring" errors, and also if you create one manually:
from error_report.models import Error()
Error.objects.create()

The fact that the pk values are incrementing would suggest that the errors are actually being created? Additionally the "after_error_logged" hook is being called (to notify the users). So, it would seem that for some reason the errors are being subsequently deleted from the database.
@matmair have you seen this?

Further investigation: The errors are there but not visible in the admin page:
>>> Error.objects.count()
33
>>> Error.objects.last()
<Error: Error object (67)>

Going to http://inventree.in.currawongeng.com.au/admin/error_report/error/67/ yields:

And the "error report" admin page is empty:

Interesting - I will try to debug

Seems to work on current master - could you provide more information on the version and deployment method?

Current master
Docker (development)

Ok, this one is on me. I have multiple setups running, and the error-report link was using the wrong base url. So the admin page was actually for a completely different install! Oops


Workflow prefix must be set

Hi,
i have downloaded the docker with community version 3.20 and i'm trying to run the democa realm on server but i'm getting the following error:

What could be the problem?

UPDATE: after i followed the openxpki-config instructions i have created an __old folder inside democa\workflow\def and i think the server found these files anyway by crashing the server for the new namespace.

NOTE: the certificate_export.yml is called certificate_privkey_export.yml
After eliminate the folder __old i've got this error:

A quick solution that I've done was to edit the change_metadata.yaml by renaming the cert_identifier_static to cert_identifier (cert_identifier_static doesn't exist in any files).
The last error i've done it by comment the two lines inside change_metadata.yaml:
- set_notify_active > EDIT_DATA ? is_notify_disabled
- set_notify_inactive > EDIT_DATA ? is_notify_pending

These two functions doesn't have an existing .yml file inside democa\workflow\global so i bypassed them.

Now the server starts correctly.

Waiting for new release without these bugs. Thanks

UPDATE: after following the openxpki-config instructions i have created an __old folder inside democa\workflow\def and i think the server found these files anyway by crashing the server for the new namespace.

NOTE: the certificate_export.yml is called certificate_privkey_export.yml
After eliminating the folder __old i've got this error:

A quick solution that I've done was to edit the change_metadata.yaml by renaming the cert_identifier_static to cert_identifier (cert_identifier_static doesn't exist in any files).
The last error that i've done was to comment the two lines inside change_metadata.yaml:
- set_notify_active > EDIT_DATA ? is_notify_disabled
- set_notify_inactive > EDIT_DATA ? is_notify_pending

These two functions doesn't have an existing .yml file inside democa\workflow\global so i bypassed them.

Now the server starts correctly.

Waiting for new release without these bugs. Thanks


Fix build

Problem
Build is broken due to the release script failing at some point. This fixes the build

Note: All schema changes require discussion. Please link the issue for context.

[ ] Your change modifies the core OpenLineage model
[ ] Your change modifies one or more OpenLineage facets

If you're contributing a new integration, please specify the scope of the integration and how/where it has been tested (e.g., Apache Spark integration supports S3 and GCS filesystem operations, tested with AWS EMR).
Checklist

[ ] You've signed-off your work
[ ] Your pull request title follows our guidelines
[ ] Your changes are accompanied by tests (if relevant)
[ ] Your change contains a small diff and is self-contained
[ ] You've updated any relevant documentation (if relevant)
[ ] You've updated the CHANGELOG.md with details about your change under the "Unreleased" section (if relevant, depending on the change, this may not be necessary)
[ ] You've versioned the core OpenLineage model or facets according to SchemaVer (if relevant)

Codecov Report

Merging #590 (4b87f7c) into main (c112e9c) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #590   +/-   ##
=======================================
  Coverage   83.90%   83.90%
=======================================
  Files          36       36
  Lines        2094     2094
=======================================
  Hits         1757     1757
  Misses        337      337

Impacted Files
Coverage Δ

client/python/openlineage/client/constants.py
100.00% <100.00%> (ø)

...ntegration/airflow/openlineage/airflow/__init__.py
100.00% <100.00%> (ø)

integration/common/openlineage/common/__init__.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Cocoapods

I'd be cool to also add Cocoapods support. I done this implementation myself last month for my library. Just follow this post and this checklist.

Thanks for the suggestion! Formatting is currently a Swift 3 prototype of sorts (I'm sure you've seen this comment here https://github.com/stephencelis/Formatting/pull/3#issuecomment-230358473). I'm going to let things percolate a bit before fully supporting this as a library.

Sure, no problem 😉


doc/release-note-3.2: DFU subsystem changelog

Added summary on the DFU subsystem changes.
Signed-off-by: Andrzej Puzdrowski<EMAIL_ADDRESS>

@nvlsianpu, can help address the comment.


chore(release): v1.0.2 🎉

:robot: I have created a release beep boop
1.0.2 (2023-09-16)
Bug Fixes

pkg: ensure package index refed correctly (c3ea26b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/whodisio/simple-oidc-auth/releases/tag/v1.0.2 :sunflower:


refactor: optimize the Dockerfile to reduce the image size

1.Add the --no-install-recommends option to the apt-get install command to reduce unnecessary installations.
2.Run the apt-get clean command after apt-get install to reduce cache.
3.Run rm -rf /var/lib/apt/lists/* after apt-get install to ensure cache is removed within the same layer.
4.Use the --no-cache-dir option when installing Python packages to reduce the size.

Hi, sorry for the late review, have you tested it already? is everything works well?

@Yeuoly yes, i have tested it, everything works well.

What about httpx, requests and jinja2, there are always some weird issues of those packages

@Yeuoly

By the way, is it possible to add a Makefile for dify-sandbox to simplify the installation, compilation, image creation, and environment cleanup of the sandbox? Most mainstream Go projects typically have a Makefile.
Also, add scripts directory to store the installation and compilation shell scripts.

By the way, is it possible to add a Makefile for dify-sandbox to simplify the installation, compilation, image creation, and environment cleanup of the sandbox? Most Go projects have a Makefile.
Also, add scripts directory to store the installation and compilation shell scripts.

I agree, but it's not urgent, but also, github workflows need to be refactored as well, maybe you can contribute it : )

@hwzhuhao It looks like there is a compilation error during docker build https://github.com/langgenius/dify-sandbox/actions/runs/10935045578/job/30356121638

https://github.com/langgenius/dify-sandbox/pull/87

代码执行节点，为什么执行几次后就变成了  bad system call ，error: operation not permitted
很多使用都遇到了这样的问题，应该怎么解决呢

@blue-long which version are you currently testing?

@hwzhuhao 0.2.9

@hwzhuhao
简单地看了一下源码 目前还没有定位到根本原因
执行成功的时候拥有的 syscall 和执行失败的时候是一样的

@blue-long You can reopen an issue and provide detailed version information and logs.

使用版本：https://github.com/langgenius/dify-sandbox/releases/tag/0.2.9
advanced_chat  work flow 代码执行节点（调用 dify-sandbox），执行很简单的 python代码，执行过程成功几次后就变成了执行失败，运行不稳定。
执行失败的时候：

dify-sandbox 走了这部分逻辑
dify-sandbox/internal/core/runner/output_capture.go
if strings.Contains(exit_string, "bad system call") {
s.WriteError([]byte("error: operation not permitted\n"))
}
拥有的 syscalls 权限是：
dify-sandbox/internal/core/lib/python/add_seccomp.go
log.Info("lib.Seccomp allowed_syscalls: %v, allowed_not_kill_syscalls: %v", allowed_syscalls, allowed_not_kill_syscalls)
err = lib.Seccomp(allowed_syscalls, allowed_not_kill_syscalls)
if err != nil {
log.Error("lib.Seccomp Error: %v", err.Error())
return err
}
[INFO]lib.Seccomp allowed_syscalls: [64 57 56 63 62 61 98 222 214 226 215 139 135 132 216 146 144 174 172 173 178 93 94 131 134 29 124 100 99 293 20 113 169 101 21 115 72 85 86 87 278], allowed_not_kill_syscalls: [220 34]
lib.Seccomp 添加 syscalls 权限，并没有报错
执行成功的时候拥有的 syscalls 权限和执行失败是一样：

[INFO]lib.Seccomp allowed_syscalls: [64 57 56 63 62 61 98 222 214 226 215 139 135 132 216 146 144 174 172 173 178 93 94 131 134 29 124 100 99 293 20 113 169 101 21 115 72 85 86 87 278], allowed_not_kill_syscalls: [220 34]

@blue-long I didn't reproduce this issue. Maybe you can try removing the allowed_syscalls setting, try it again.

这个问题做相关的分析，发现 sandbox 0.2.9 的 docker 镜像在 centOS 系统上部署，一切正常，没有出现 operation not permitted  问题，
但是部署在 ubuntu 的系统上，就会出现  operation not permitted 的问题，
可以提供一个基于 ubuntu  构建的 docker  sandbox 0.2.9 镜像吗


Add global setting for mailhog (or its replacement) port

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem?
The "problem" is that while the router ports can now be global config, mailhog ports are not yet and they conflict for me on every project because I have a non-docker installation of that as well.
Describe your solution
Add a global setting for that.
I've seen https://github.com/ddev/ddev/issues/4827, so that will obviously conflict with that. the global setting could have a generic name that doesn't actually use the name mailhog so it doesn't need to be updated if the used solution changes?
Describe alternatives
No response
Additional context
No response

Have you considered running your external mailhog on a different port? Simple solution...

I hit this the other day trying to run ddev on two different WSL2 distros at the same time. Easy to move the main ports, more work to move this one.

Please test

https://github.com/ddev/ddev/pull/5313#issuecomment-1701826686

The global setting is now available in HEAD. Hope you like it!


Install apollo in centos system

Since apollo is running in a docker container, can I install docker in the centos system and then install apollo?
既然apollo是运行在docker 容器中，那么我可以在centos系统中安装docker，然后安装apollo吗

It seems feasible, but I don’t think it is recommended.
First, you need to make sure that the kernel version of the system is the same. Second, you need to pay attention to whether some library files are compatible.

Since apollo is running in a docker container, can I install docker in the centos system and then install apollo?
既然apollo是运行在docker 容器中，那么我可以在centos系统中安装docker，然后安装apollo吗

I think It should be relatively easy to install Apollo docker on a CentOS system. But we haven't test this yet. You can have a try if you have some experience developing on Linux and using docker. Share your experience with everyone here if you would like.

This ticket is being closed. Please raise other issues if needed. Thanks for using Apollo.


Animation track data not being instanced

Godot version:
master 5a5614e8adcc49b92621dc2f39364385769d36a0
OS/device including version:
ubuntu, nvidia
Issue description:
I have a Scene of a Button, an AnimationPlayer and a Timer. The AnimationPlayer has a "slide in" animation that moves the button the width of the button to the left. I do this by using track_set_key_value on the Animation in the Timer to set the final keyframe position x to the width of the Button text.

But if the Timer timeout is called before another instance's track has finished, the other instance's animation track data is changed and it messes up.
I think this might be because the track data in an Animation inside an AnimationPlayer is not being instanced but rather shared. I say this because in the Timer timeout function, "self" contains a unique instanced object so I would expect the animations to be unique too.
Here's a project that shows the behaviour. 14 Scenes instanced. The first seven display correctly since their Timers timeout without overlap but the next 7 Scenes have shorter times that overlap and so overwrite each other and their animations go wonky.
GodotEditAnimTrack.zip
Minimal reproduction project:

I had this problem too in my game, and I solved it the same way as we solve it for modifying materials at runtime: I make them unique in my script.

Hey thanks for replying.
Would I have duplicate the tracks or just the animation player?
There is an option in the inspector on AnimationPlayer to "make sub-resources unique" but after I select it none of the animations play so I have no idea what it does.

@dodgyville you have to duplicate the animation you are modifying within the AnimationPlayer (is animation is a resource). track_set_key_value is a method of Animation, you are clearly modifying it, so you need to make it unique, and at runtime.

I have duplicated the Animation and copied across the Animation Track data. The duplicate animation plays but I am unable to edit the keyframes in the code. Calling new_animation.track_get_key_count(track_id)) returns zero when I know there are five keyframes and I can see them being hit on the screen when it plays the animation.
    # duplicate Animation to make it unique
    var orig_anim_title = "original"
    var unique_anim_title = "duplicate"

    var aplayer = self.get_node("Button/AnimationPlayer")
    var anim = aplayer.get_animation(orig_anim_title)
    var unique_anim = anim.duplicate()
    aplayer.add_animation(unique_anim_title, unique_anim)
    for track_id in anim.get_track_count(): # copy tracks to new animation
        var track = anim.copy_track(track_id, unique_anim)

    var new_anim = self.get_node("Button/AnimationPlayer").get_animation(unique_anim_title)
    var track_id = new_anim.find_track(".:rect_position")
    print("track key count",new_anim.track_get_key_count(track_id))
    # should print the number of keys in the track? which is about five.

    aplayer.play(unique_anim_title)

    var unique_anim = anim.duplicate()
Doing this should already copy all tracks, keep in mind tracks ARE in the Animation, there is no need to copy them again because it's duplicate's job.
If you find different number of keys then maybe it's broken?

I initially did just anim.duplicate() but there didn't appear to be any tracks on the new animation (don't quote me on that though)

yeah, I tried to duplicate Animation again and I just can not get it working. The animation is there but playing it does nothing, as if there is no track data.

Is this still reproducible in 3.1?

Hello, I have a a similar scene and can confirm the animations are not running after duplicate in godot 3.1.

It's pretty weird, but yes it does seem reproducible with the project in OP (note that you need to tweak a script to add_child() the instanced node which contains the timer before starting said timer).

Can't reproduce in 4.4, tested with this code:
func _ready() -> void:
	var player: AnimationPlayer = $AnimationPlayer

	var animation := player.get_animation("new_animation")
	animation = animation.duplicate()
	player.get_animation_library("").add_animation("newer_animation", animation)

	player.play("newer_animation")


Advection changes from HICAR merge

TYPE: new feature
KEYWORDS: Advection, higher-order, structural, flux-limiter
SOURCE: Dylan Reynolds, SLF
DESCRIPTION OF CHANGES: These changes first generalize advection in the model such that the advection driver loops through a dictionary of advectable variables stored in the domain object. The driver then calls individual advection routines from each advection module. The upwind module has been changed to be a 'standard' advection scheme, where different spatial differencing stencils can be applied from the namelist. In this way, upwind becomes just a particular case of the 'standard' advection scheme. RK3 time-stepping is also facilitated for the advection variables through the advection driver, and the necesarry flux limiter is added to allow this. Both the flux limiter and the spatial orders of the advection scheme are now namelist options under advection options.
These changes also necessitated making the grid halo variable in size. This is why higher order schemes and the flux limiter have a large hit on computation time: they require more data to be exchanged through CoArrays. So note that going to a higher order advection scheme will have a doubling/trippling/etc effect on the run time over the upwind scheme, but we have seen justifiable improvements in essentially all advected fields as a result.
NOTES: These changes have been found to have a large impact on precipitation, especially at high resolutions and in complex terrain. Running with horder, vorder=3, flux_corr=1 is recommended for a performance/computation tradeoff.
Documentation to follow once all HICAR merges are complete

Cool integration test feature -- where can I change the namelist that it uses?

@gutmann the CI tests are now passing with the commits I made. Once these are in the hicar branch then they can be pulled into PR #157 and that PR should pass as well, it did with my tests at least.


AE.replacesearch removing default search from non-shift context menu

I think AE.replacesearch is removing the search from the menu when dragging without holding shift.

Indeed it was. Fixed in 4.4.1


Fix eaten async for function with labelled args

This PR fixes #674

I don't know the history of why letting the pexp_fun with nolabel arg keeps the attributes. https://github.com/rescript-lang/syntax/blob/a3c27ef3011e1c37ee3c2fbf8229f4dca49d3de7/src/res_parsetree_viewer.ml#L176

This PR allows the Pexp_fun with labeled and optional to keep the res.async attribute only.

Oops, I had another fix done on the plane:
https://github.com/rescript-lang/syntax/pull/677

Basically, for (@foo ~a) => ... when one wants to put an attribute on the label, there's no way to represent this directly in the AST, as labelled args don't have attributes.
So the convention is to take the attributes on the function, and consider them applied to the label.
This does not fit well with the fact that async is put on the function, and some adjustment is needed.

There was a reason! Thank you for the explanation. I couldn't guess it. 👍

I'm going to close this PR, #677 will fix the issue.


Add support for bitbucket headers.

Closes #174

@zhongxiao37 would you like to add some tests for it?


xtf: 0-unstable-2024-09-13 -> 0-unstable-2024-11-01

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for xtf is: Xen Test Framework and Suite for creating microkernel-based tests
meta.homepage for xtf is: https://xenbits.xenproject.org/docs/xtf/index.html
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0-unstable-2024-11-01 in filename of file in /nix/store/i44ixpjcbnhjbn61rfr61b912y07f3g3-xtf-0-unstable-2024-11-01

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

xtf

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/i44ixpjcbnhjbn61rfr61b912y07f3g3-xtf-0-unstable-2024-11-01 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A xtf https://github.com/r-ryantm/nixpkgs/archive/252c782e2cdc60fd8c52a4cd8e2e7ba5e6d2c168.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/252c782e2cdc60fd8c52a4cd8e2e7ba5e6d2c168#xtf

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/i44ixpjcbnhjbn61rfr61b912y07f3g3-xtf-0-unstable-2024-11-01
ls -la /nix/store/i44ixpjcbnhjbn61rfr61b912y07f3g3-xtf-0-unstable-2024-11-01/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 3 packages built:

xtf
xtf.dev
xtf.doc

Maintainer pings
cc @hehongbo @CertainLach @SigmaSquadron for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge