Arrow install on Databricks cluster takes 10+ minutes

I'm installing arrow on a high concurrency cluster within Databricks, but every time the cluster spins up it seems to be taking longer and longer to install. I'm using the default repository and my Databricks Runtime is 10.1, which includes Apache Spark 3.2.0. Any feedback or suggestions are appreciated. Thanks!

Hi James, is this pyarrow you are talking about? Which version are you installing? And are there any logs you can share?

@wjones127 This is for conjunction with SparkR, essentially taking some Legacy code and optimizing the collects() into R dataframes so we can leverage Delta tables while making minimal changes to the existing codebase. I'm using the CRAN option to install it onto my cluster. Using arrow version 7.0.0. I looked through the driver logs and nothing immediately pops out as being relevant for the arrow install, but I can send those if you want it. Here's my cluster config as well for reference:

It sounds like it's building the R package each time. Have you tried using the RStudio package manager as the repo?
In R the call would be:
install.packages("arrow", repos = "https://packagemanager.rstudio.com/all/__linux__/focal/latest")

It looks like in the Databricks UI you can set the repo.

@wjones127 I've been letting the install run for a while now but it seems to be stuck on "pending"

Not sure if the OS needs to be switched in the URL or if it's another issue

Hmm yeah that's odd. Is focal not the right OS name for DBR 10.1?
Might be worth trying the notebook-scoped command and see if that works. Should at least get better logs.
I'd recomend taking the arrow package off the cluster config, and then starting up the cluster and running:
install.packages("arrow")
install.packages("arrow", repos = "https://packagemanager.rstudio.com/all/__linux__/focal/latest")

And see how the time and output compare between the two. I suspect the first is building the C++ code, while the latter (if it works) should not be.

To use RStudio Package Manager, we needs to set up the UA header.
Please check this page. https://docs.rstudio.com/rspm/admin/serving-binaries/#binary-user-agents

@wjones127 Here's the logs from running install.packages("arrow", repos = "https://packagemanager.rstudio.com/all/linux/focal/latest"). Ran in ~16 minutes
`* installing source package ‘arrow’ ...
** package ‘arrow’ successfully unpacked and MD5 sums checked
** using staged installation
**** pkg-config not installed, setting ARROW_DEPENDENCY_SOURCE=BUNDLED
trying URL 'https://github.com'
downloaded 203 KB
*** Using ubuntu-18.04 binary for ubuntu-20.04
trying URL 'https://arrow-r-nightly.s3.amazonaws.com/libarrow/bin/ubuntu-18.04/arrow-7.0.0.zip'
Error in download.file(from_url, to_file, quiet = quietly) :
cannot open URL 'https://arrow-r-nightly.s3.amazonaws.com/libarrow/bin/ubuntu-18.04/arrow-7.0.0.zip'
*** No libarrow binary found for version 7.0.0 on ubuntu-18.04
*** Found local C++ source: 'tools/cpp'
*** Building libarrow from source
For a faster, more complete installation, set the environment variable NOT_CRAN=true before installing
See install vignette for details:
https://cran.r-project.org/web/packages/arrow/vignettes/install.html
*** Building with MAKEFLAGS= -j2
**** arrow with SOURCE_DIR='tools/cpp' BUILD_DIR='/tmp/RtmpRLVXZh/file20721bb0e480' DEST_DIR='libarrow/arrow-7.0.0' CMAKE='/usr/bin/cmake' EXTRA_CMAKE_FLAGS='' CC='gcc -std=gnu99' CXX='g++ -std=gnu++11' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' ARROW_S3='ON' ARROW_MIMALLOC='ON'
++ pwd

: /tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow
: tools/cpp
: /tmp/RtmpRLVXZh/file20721bb0e480
: libarrow/arrow-7.0.0
: /usr/bin/cmake
++ cd tools/cpp
++ pwd
SOURCE_DIR=/tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/tools/cpp
++ mkdir -p libarrow/arrow-7.0.0
++ cd libarrow/arrow-7.0.0
++ pwd
DEST_DIR=/tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/libarrow/arrow-7.0.0
'[' false '!=' '' ']'
++ echo false
++ tr '[:upper:]' '[:lower:]'
LIBARROW_MINIMAL=false
'[' false = false ']'
ARROW_DEFAULT_PARAM=ON
mkdir -p /tmp/RtmpRLVXZh/file20721bb0e480
pushd /tmp/RtmpRLVXZh/file20721bb0e480
/tmp/RtmpRLVXZh/file20721bb0e480 /tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow
/usr/bin/cmake -DARROW_BOOST_USE_SHARED=OFF -DARROW_BUILD_TESTS=OFF -DARROW_BUILD_SHARED=OFF -DARROW_BUILD_STATIC=ON -DARROW_COMPUTE=ON -DARROW_CSV=ON -DARROW_DATASET=ON -DARROW_DEPENDENCY_SOURCE=BUNDLED -DAWSSDK_SOURCE= -DARROW_FILESYSTEM=ON -DARROW_JEMALLOC=ON -DARROW_MIMALLOC=ON -DARROW_JSON=ON -DARROW_PARQUET=ON -DARROW_S3=ON -DARROW_WITH_BROTLI=ON -DARROW_WITH_BZ2=ON -DARROW_WITH_LZ4=ON -DARROW_WITH_RE2=ON -DARROW_WITH_SNAPPY=ON -DARROW_WITH_UTF8PROC=ON -DARROW_WITH_ZLIB=ON -DARROW_WITH_ZSTD=ON -DARROW_VERBOSE_THIRDPARTY_BUILD=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_LIBDIR=lib -DCMAKE_INSTALL_PREFIX=/tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/libarrow/arrow-7.0.0 -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_UNITY_BUILD=OFF -G 'Unix Makefiles' /tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/tools/cpp
-- Building using CMake version: 3.16.3
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Arrow version: 7.0.0 (full: '7.0.0')
-- Arrow SO version: 700 (full: 700.0.0)
-- clang-tidy 12 not found
-- clang-format 12 not found
-- Could NOT find ClangTools (missing: CLANG_FORMAT_BIN CLANG_TIDY_BIN)
-- infer not found
fatal: not a git repository (or any of the parent directories): .git
-- Found Python3: /databricks/python3/bin/python3.8 (found version "3.8.10") found components: Interpreter
-- Found cpplint executable at /tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/tools/cpp/build-support/cpplint.py
-- System processor: x86_64
-- Performing Test CXX_SUPPORTS_SSE4_2
-- Performing Test CXX_SUPPORTS_SSE4_2 - Success
-- Performing Test CXX_SUPPORTS_AVX2
-- Performing Test CXX_SUPPORTS_AVX2 - Success
-- Performing Test CXX_SUPPORTS_AVX512
-- Performing Test CXX_SUPPORTS_AVX512 - Success
-- Arrow build warning level: PRODUCTION
Using ld linker
Configured for RELEASE build (set with cmake -DCMAKE_BUILD_TYPE={release,debug,...})
-- Build Type: RELEASE
-- Using BUNDLED approach to find dependencies
-- ARROW_ABSL_BUILD_VERSION: 20210324.2
-- ARROW_ABSL_BUILD_SHA256_CHECKSUM: 59b862f50e710277f8ede96f083a5bb8d7c9595376146838b9580be90374ee1f
-- ARROW_AWSSDK_BUILD_VERSION: 1.8.133
-- ARROW_AWSSDK_BUILD_SHA256_CHECKSUM: d6c495bc06be5e21dac716571305d77437e7cfd62a2226b8fe48d9ab5785a8d6
-- ARROW_AWS_CHECKSUMS_BUILD_VERSION: v0.1.12
-- ARROW_AWS_CHECKSUMS_BUILD_SHA256_CHECKSUM: 394723034b81cc7cd528401775bc7aca2b12c7471c92350c80a0e2fb9d2909fe
-- ARROW_AWS_C_COMMON_BUILD_VERSION: v0.6.9
-- ARROW_AWS_C_COMMON_BUILD_SHA256_CHECKSUM: 928a3e36f24d1ee46f9eec360ec5cebfe8b9b8994fe39d4fa74ff51aebb12717
-- ARROW_AWS_C_EVENT_STREAM_BUILD_VERSION: v0.1.5
-- ARROW_AWS_C_EVENT_STREAM_BUILD_SHA256_CHECKSUM: f1b423a487b5d6dca118bfc0d0c6cc596dc476b282258a3228e73a8f730422d4
-- ARROW_BOOST_BUILD_VERSION: 1.75.0
-- ARROW_BOOST_BUILD_SHA256_CHECKSUM: 267e04a7c0bfe85daf796dedc789c3a27a76707e1c968f0a2a87bb96331e2b61
-- ARROW_BROTLI_BUILD_VERSION: v1.0.9
-- ARROW_BROTLI_BUILD_SHA256_CHECKSUM: f9e8d81d0405ba66d181529af42a3354f838c939095ff99930da6aa9cdf6fe46
-- ARROW_BZIP2_BUILD_VERSION: 1.0.8
-- ARROW_BZIP2_BUILD_SHA256_CHECKSUM: ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269
-- ARROW_CARES_BUILD_VERSION: 1.17.2
-- ARROW_CARES_BUILD_SHA256_CHECKSUM: 4803c844ce20ce510ef0eb83f8ea41fa24ecaae9d280c468c582d2bb25b3913d
-- ARROW_CRC32C_BUILD_VERSION: 1.1.2
-- ARROW_CRC32C_BUILD_SHA256_CHECKSUM: ac07840513072b7fcebda6e821068aa04889018f24e10e46181068fb214d7e56
-- ARROW_GBENCHMARK_BUILD_VERSION: v1.6.0
-- ARROW_GBENCHMARK_BUILD_SHA256_CHECKSUM: 1f71c72ce08d2c1310011ea6436b31e39ccab8c2db94186d26657d41747c85d6
-- ARROW_GFLAGS_BUILD_VERSION: v2.2.2
-- ARROW_GFLAGS_BUILD_SHA256_CHECKSUM: 34af2f15cf7367513b352bdcd2493ab14ce43692d2dcd9dfc499492966c64dcf
-- ARROW_GLOG_BUILD_VERSION: v0.5.0
-- ARROW_GLOG_BUILD_SHA256_CHECKSUM: eede71f28371bf39aa69b45de23b329d37214016e2055269b3b5e7cfd40b59f5
-- ARROW_GOOGLE_CLOUD_CPP_BUILD_VERSION: v1.35.0
-- ARROW_GOOGLE_CLOUD_CPP_BUILD_SHA256_CHECKSUM: e4e9eac1e7999eff195db270bc2a719004660b3730ebb5d2f444f2d2057e49b2
-- ARROW_GRPC_BUILD_VERSION: v1.35.0
-- ARROW_GRPC_BUILD_SHA256_CHECKSUM: 27dd2fc5c9809ddcde8eb6fa1fa278a3486566dfc28335fca13eb8df8bd3b958
-- ARROW_GTEST_BUILD_VERSION: 1.11.0
-- ARROW_GTEST_BUILD_SHA256_CHECKSUM: b4870bf121ff7795ba20d20bcdd8627b8e088f2d1dab299a031c1034eddc93d5
-- ARROW_JEMALLOC_BUILD_VERSION: 5.2.1
-- ARROW_JEMALLOC_BUILD_SHA256_CHECKSUM: 34330e5ce276099e2e8950d9335db5a875689a4c6a56751ef3b1d8c537f887f6
-- ARROW_LZ4_BUILD_VERSION: 8f61d8eb7c6979769a484cde8df61ff7c4c77765
-- ARROW_LZ4_BUILD_SHA256_CHECKSUM: 5b072d848f2f93fddb97e1143e22c1bd7fa19fc8431ee69e21758190a88125b4
-- ARROW_MIMALLOC_BUILD_VERSION: v1.7.3
-- ARROW_MIMALLOC_BUILD_SHA256_CHECKSUM: 0f987bda01ca9df87ec90e9d98c63fa893ee61f3cca565e5ca5ed744fdcc5109
-- ARROW_NLOHMANN_JSON_BUILD_VERSION: v3.10.2
-- ARROW_NLOHMANN_JSON_BUILD_SHA256_CHECKSUM: 081ed0f9f89805c2d96335c3acfa993b39a0a5b4b4cef7edb68dd2210a13458c
-- ARROW_OPENTELEMETRY_BUILD_VERSION: v1.1.0
-- ARROW_OPENTELEMETRY_BUILD_SHA256_CHECKSUM: f8fd3adddd47be382dc79c19d7e7efcf86a0dfbb5a237db6e0618dbb7eb8e058
-- ARROW_OPENTELEMETRY_PROTO_BUILD_VERSION: v0.11.0
-- ARROW_OPENTELEMETRY_PROTO_BUILD_SHA256_CHECKSUM: 985367f8905e91018e636cbf0d83ab3f834b665c4f5899a27d10cae9657710e2
-- ARROW_ORC_BUILD_VERSION: 1.7.2
-- ARROW_ORC_BUILD_SHA256_CHECKSUM: ef39bae755116fecb07fb4334656f984ba8ce7cdb1c64de078d3ed186b286007
-- ARROW_PROTOBUF_BUILD_VERSION: v3.18.1
-- ARROW_PROTOBUF_BUILD_SHA256_CHECKSUM: b8ab9bbdf0c6968cf20060794bc61e231fae82aaf69d6e3577c154181991f576
-- ARROW_RAPIDJSON_BUILD_VERSION: 1a803826f1197b5e30703afe4b9c0e7dd48074f5
-- ARROW_RAPIDJSON_BUILD_SHA256_CHECKSUM: 0b6b780b6c534bfb0b23d29910bfe361e486bcfeaf106db8bc8995792072905a
-- ARROW_RE2_BUILD_VERSION: 2021-11-01
-- ARROW_RE2_BUILD_SHA256_CHECKSUM: 8c45f7fba029ab41f2a7e6545058d9eec94eef97ce70df58e92d85cfc08b4669
-- ARROW_SNAPPY_BUILD_VERSION: 1.1.9
-- ARROW_SNAPPY_BUILD_SHA256_CHECKSUM: 75c1fbb3d618dd3a0483bff0e26d0a92b495bbe5059c8b4f1c962b478b6e06e7
-- ARROW_SNAPPY_OLD_BUILD_VERSION: 1.1.8
-- ARROW_SNAPPY_OLD_BUILD_SHA256_CHECKSUM: 16b677f07832a612b0836178db7f374e414f94657c138e6993cbfc5dcc58651f
-- ARROW_THRIFT_BUILD_VERSION: 0.13.0
-- ARROW_THRIFT_BUILD_SHA256_CHECKSUM: 7ad348b88033af46ce49148097afe354d513c1fca7c607b59c33ebb6064b5179
-- ARROW_UTF8PROC_BUILD_VERSION: v2.7.0
-- ARROW_UTF8PROC_BUILD_SHA256_CHECKSUM: 4bb121e297293c0fd55f08f83afab6d35d48f0af4ecc07523ad8ec99aa2b12a1
-- ARROW_XSIMD_BUILD_VERSION: aeec9c872c8b475dedd7781336710f2dd2666cb2
-- ARROW_XSIMD_BUILD_SHA256_CHECKSUM: 0a841e6c8acf216150e4fc19fca8e29fbab9614b56ac7b96e56019264ca27b26
-- ARROW_ZLIB_BUILD_VERSION: 1.2.11
-- ARROW_ZLIB_BUILD_SHA256_CHECKSUM: c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1
-- ARROW_ZSTD_BUILD_VERSION: v1.5.1
-- ARROW_ZSTD_BUILD_SHA256_CHECKSUM: dc05773342b28f11658604381afd22cb0a13e8ba17ff2bd7516df377060c18dd
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Looking for _M_ARM64
-- Looking for _M_ARM64 - not found
-- Looking for SIZEOF_INT128
-- Looking for SIZEOF_INT128 - found
-- Boost include dir: /tmp/RtmpRLVXZh/file20721bb0e480/boost_ep-prefix/src/boost_ep
-- Boost libraries: boost_system_static;boost_filesystem_static
-- Building snappy from source
-- Building brotli from source
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found suitable version "1.1.1f", minimum required is "1.0.2")
-- Found OpenSSL Crypto Library: /usr/lib/x86_64-linux-gnu/libcrypto.so
-- Building with OpenSSL (Version: 1.1.1f) support
Building Apache Thrift from source
-- Building (vendored) jemalloc from source
-- Building (vendored) mimalloc from source
-- Building RapidJSON from source
-- Building xsimd from source
-- Building ZLIB from source
-- Building lz4 from source
-- Building zstd from source
-- Building RE2 from source
-- Building BZip2 from source
-- Building utf8proc from source
-- Found hdfs.h at: /tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/tools/cpp/thirdparty/hadoop/include/hdfs.h
Building AWS C++ SDK from source
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.68.0")
-- Found AWS SDK headers: /tmp/RtmpRLVXZh/file20721bb0e480/awssdk_ep-install/include
-- Found AWS SDK libraries: aws-cpp-sdk-identity-management;aws-cpp-sdk-sts;aws-cpp-sdk-cognito-identity;aws-cpp-sdk-s3;aws-cpp-sdk-core;AWS::aws-c-event-stream;AWS::aws-checksums;AWS::aws-c-common
-- All bundled static libraries: Snappy::snappy;Brotli::brotlicommon;Brotli::brotlienc;Brotli::brotlidec;thrift::thrift;jemalloc::jemalloc;mimalloc::mimalloc;ZLIB::ZLIB;LZ4::lz4;zstd::libzstd;re2::re2;BZip2::BZip2;utf8proc::utf8proc;aws-cpp-sdk-identity-management;aws-cpp-sdk-sts;aws-cpp-sdk-cognito-identity;aws-cpp-sdk-s3;aws-cpp-sdk-core;AWS::aws-c-event-stream;AWS::aws-checksums;AWS::aws-c-common
-- CMAKE_C_FLAGS:  -O3 -DNDEBUG  -Wall -fno-semantic-interposition -msse4.2
-- CMAKE_CXX_FLAGS:  -Wno-noexcept-type  -fdiagnostics-color=always -O3 -DNDEBUG  -Wall -fno-semantic-interposition -msse4.2
-- Looking for backtrace
-- Looking for backtrace - found
-- backtrace facility detected in default set of libraries
-- Found Backtrace: /usr/include
-- Creating bundled static library target arrow_bundled_dependencies at /tmp/RtmpRLVXZh/file20721bb0e480/release/libarrow_bundled_dependencies.a

-- Arrow version:                                 7.0.0
-- Build configuration summary:
--   Generator: Unix Makefiles
--   Build type: RELEASE
--   Source directory: /tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/tools/cpp
--   Install prefix: /tmp/RtmphLsRtL/R.INSTALL205114eb9ae3/arrow/libarrow/arrow-7.0.0
-- Compile and link options:
--   ARROW_CXXFLAGS="" [default=""]
--       Compiler flags to append when compiling Arrow
--   ARROW_BUILD_STATIC=ON [default=ON]
--       Build static libraries
--   ARROW_BUILD_SHARED=OFF [default=ON]
--       Build shared libraries
--   ARROW_PACKAGE_KIND="" [default=""]
--       Arbitrary string that identifies the kind of package
--       (for informational purposes)
--   ARROW_GIT_ID="" [default=""]
--       The Arrow git commit id (if any)
--   ARROW_GIT_DESCRIPTION="" [default=""]
--       The Arrow git commit description (if any)
--   ARROW_NO_DEPRECATED_API=OFF [default=OFF]
--       Exclude deprecated APIs from build
--   ARROW_USE_CCACHE=ON [default=ON]
--       Use ccache when compiling (if available)
--   ARROW_USE_LD_GOLD=OFF [default=OFF]
--       Use ld.gold for linking on Linux (if available)
--   ARROW_USE_PRECOMPILED_HEADERS=OFF [default=OFF]
--       Use precompiled headers when compiling
--   ARROW_SIMD_LEVEL=SSE4_2 [default=NONE|SSE4_2|AVX2|AVX512|NEON|DEFAULT]
--       Compile-time SIMD optimization level
--   ARROW_RUNTIME_SIMD_LEVEL=MAX [default=NONE|SSE4_2|AVX2|AVX512|MAX]
--       Max runtime SIMD optimization level
--   ARROW_ARMV8_ARCH=armv8-a [default=armv8-a|armv8-a+crc+crypto]
--       Arm64 arch and extensions
--   ARROW_ALTIVEC=ON [default=ON]
--       Build with Altivec if compiler has support
--   ARROW_RPATH_ORIGIN=OFF [default=OFF]
--       Build Arrow libraries with RATH set to $ORIGIN
--   ARROW_INSTALL_NAME_RPATH=ON [default=ON]
--       Build Arrow libraries with install_name set to @rpath
--   ARROW_GGDB_DEBUG=ON [default=ON]
--       Pass -ggdb flag to debug builds
-- Test and benchmark options:
--   ARROW_BUILD_EXAMPLES=OFF [default=OFF]
--       Build the Arrow examples
--   ARROW_BUILD_TESTS=OFF [default=OFF]
--       Build the Arrow googletest unit tests
--   ARROW_ENABLE_TIMING_TESTS=ON [default=ON]
--       Enable timing-sensitive tests
--   ARROW_BUILD_INTEGRATION=OFF [default=OFF]
--       Build the Arrow integration test executables
--   ARROW_BUILD_BENCHMARKS=OFF [default=OFF]
--       Build the Arrow micro benchmarks
--   ARROW_BUILD_BENCHMARKS_REFERENCE=OFF [default=OFF]
--       Build the Arrow micro reference benchmarks
--   ARROW_BUILD_OPENMP_BENCHMARKS=OFF [default=OFF]
--       Build the Arrow benchmarks that rely on OpenMP
--   ARROW_BUILD_DETAILED_BENCHMARKS=OFF [default=OFF]
--       Build benchmarks that do a longer exploration of performance
--   ARROW_TEST_LINKAGE=static [default=shared|static]
--       Linkage of Arrow libraries with unit tests executables.
--   ARROW_FUZZING=OFF [default=OFF]
--       Build Arrow Fuzzing executables
--   ARROW_LARGE_MEMORY_TESTS=OFF [default=OFF]
--       Enable unit tests which use large memory
-- Lint options:
--   ARROW_ONLY_LINT=OFF [default=OFF]
--       Only define the lint and check-format targets
--   ARROW_VERBOSE_LINT=OFF [default=OFF]
--       If off, 'quiet' flags will be passed to linting tools
--   ARROW_GENERATE_COVERAGE=OFF [default=OFF]
--       Build with C++ code coverage enabled
-- Checks options:
--   ARROW_TEST_MEMCHECK=OFF [default=OFF]
--       Run the test suite using valgrind --tool=memcheck
--   ARROW_USE_ASAN=OFF [default=OFF]
--       Enable Address Sanitizer checks
--   ARROW_USE_TSAN=OFF [default=OFF]
--       Enable Thread Sanitizer checks
--   ARROW_USE_UBSAN=OFF [default=OFF]
--       Enable Undefined Behavior sanitizer checks
-- Project component options:
--   ARROW_BUILD_UTILITIES=OFF [default=OFF]
--       Build Arrow commandline utilities
--   ARROW_COMPUTE=ON [default=OFF]
--       Build the Arrow Compute Modules
--   ARROW_CSV=ON [default=OFF]
--       Build the Arrow CSV Parser Module
--   ARROW_CUDA=OFF [default=OFF]
--       Build the Arrow CUDA extensions (requires CUDA toolkit)
--   ARROW_DATASET=ON [default=OFF]
--       Build the Arrow Dataset Modules
--   ARROW_ENGINE=OFF [default=OFF]
--       Build the Arrow Execution Engine
--   ARROW_FILESYSTEM=ON [default=OFF]
--       Build the Arrow Filesystem Layer
--   ARROW_FLIGHT=OFF [default=OFF]
--       Build the Arrow Flight RPC System (requires GRPC, Protocol Buffers)
--   ARROW_FLIGHT_SQL=OFF [default=OFF]
--       Build the Arrow Flight SQL extension
--   ARROW_GANDIVA=OFF [default=OFF]
--       Build the Gandiva libraries
--   ARROW_GCS=OFF [default=OFF]
--       Build Arrow with GCS support (requires the GCloud SDK for C++)
--   ARROW_HDFS=OFF [default=OFF]
--       Build the Arrow HDFS bridge
--   ARROW_HIVESERVER2=OFF [default=OFF]
--       Build the HiveServer2 client and Arrow adapter
--   ARROW_IPC=ON [default=ON]
--       Build the Arrow IPC extensions
--   ARROW_JEMALLOC=ON [default=ON]
--       Build the Arrow jemalloc-based allocator
--   ARROW_JNI=OFF [default=OFF]
--       Build the Arrow JNI lib
--   ARROW_JSON=ON [default=OFF]
--       Build Arrow with JSON support (requires RapidJSON)
--   ARROW_MIMALLOC=ON [default=OFF]
--       Build the Arrow mimalloc-based allocator
--   ARROW_PARQUET=ON [default=OFF]
--       Build the Parquet libraries
--   ARROW_ORC=OFF [default=OFF]
--       Build the Arrow ORC adapter
--   ARROW_PLASMA=OFF [default=OFF]
--       Build the plasma object store along with Arrow
--   ARROW_PLASMA_JAVA_CLIENT=OFF [default=OFF]
--       Build the plasma object store java client
--   ARROW_PYTHON=OFF [default=OFF]
--       Build the Arrow CPython extensions
--   ARROW_S3=ON [default=OFF]
--       Build Arrow with S3 support (requires the AWS SDK for C++)
--   ARROW_SKYHOOK=OFF [default=OFF]
--       Build the Skyhook libraries
--   ARROW_TENSORFLOW=OFF [default=OFF]
--       Build Arrow with TensorFlow support enabled
--   ARROW_TESTING=OFF [default=OFF]
--       Build the Arrow testing libraries
-- Thirdparty toolchain options:
--   ARROW_DEPENDENCY_SOURCE=BUNDLED [default=AUTO|BUNDLED|SYSTEM|CONDA|VCPKG|BREW]
--       Method to use for acquiring arrow's build dependencies
--   ARROW_VERBOSE_THIRDPARTY_BUILD=OFF [default=OFF]
--       Show output from ExternalProjects rather than just logging to files
--   ARROW_DEPENDENCY_USE_SHARED=ON [default=ON]
--       Link to shared libraries
--   ARROW_BOOST_USE_SHARED=OFF [default=ON]
--       Rely on boost shared libraries where relevant
--   ARROW_BROTLI_USE_SHARED=ON [default=ON]
--       Rely on Brotli shared libraries where relevant
--   ARROW_BZ2_USE_SHARED=ON [default=ON]
--       Rely on Bz2 shared libraries where relevant
--   ARROW_GFLAGS_USE_SHARED=ON [default=ON]
--       Rely on GFlags shared libraries where relevant
--   ARROW_GRPC_USE_SHARED=ON [default=ON]
--       Rely on gRPC shared libraries where relevant
--   ARROW_LZ4_USE_SHARED=ON [default=ON]
--       Rely on lz4 shared libraries where relevant
--   ARROW_OPENSSL_USE_SHARED=ON [default=ON]
--       Rely on OpenSSL shared libraries where relevant
--   ARROW_PROTOBUF_USE_SHARED=ON [default=ON]
--       Rely on Protocol Buffers shared libraries where relevant
--   ARROW_THRIFT_USE_SHARED=ON [default=ON]
--       Rely on thrift shared libraries where relevant
--   ARROW_UTF8PROC_USE_SHARED=ON [default=ON]
--       Rely on utf8proc shared libraries where relevant
--   ARROW_SNAPPY_USE_SHARED=ON [default=ON]
--       Rely on snappy shared libraries where relevant
--   ARROW_UTF8PROC_USE_SHARED=ON [default=ON]
--       Rely on utf8proc shared libraries where relevant
--   ARROW_ZSTD_USE_SHARED=ON [default=ON]
--       Rely on zstd shared libraries where relevant
--   ARROW_USE_GLOG=OFF [default=OFF]
--       Build libraries with glog support for pluggable logging
--   ARROW_WITH_BACKTRACE=ON [default=ON]
--       Build with backtrace support
--   ARROW_WITH_OPENTELEMETRY=OFF [default=OFF]
--       Build libraries with OpenTelemetry support for distributed tracing
--   ARROW_WITH_BROTLI=ON [default=OFF]
--       Build with Brotli compression
--   ARROW_WITH_BZ2=ON [default=OFF]
--       Build with BZ2 compression
--   ARROW_WITH_LZ4=ON [default=OFF]
--       Build with lz4 compression
--   ARROW_WITH_SNAPPY=ON [default=OFF]
--       Build with Snappy compression
--   ARROW_WITH_ZLIB=ON [default=OFF]
--       Build with zlib compression
--   ARROW_WITH_ZSTD=ON [default=OFF]
--       Build with zstd compression
--   ARROW_WITH_UTF8PROC=ON [default=ON]
--       Build with support for Unicode properties using the utf8proc library
--       (only used if ARROW_COMPUTE is ON or ARROW_GANDIVA is ON)
--   ARROW_WITH_RE2=ON [default=ON]
--       Build with support for regular expressions using the re2 library
--       (only used if ARROW_COMPUTE or ARROW_GANDIVA is ON)
-- Parquet options:
--   PARQUET_MINIMAL_DEPENDENCY=OFF [default=OFF]
--       Depend only on Thirdparty headers to build libparquet.
--       Always OFF if building binaries
--   PARQUET_BUILD_EXECUTABLES=OFF [default=OFF]
--       Build the Parquet executable CLI tools. Requires static libraries to be built.
--   PARQUET_BUILD_EXAMPLES=OFF [default=OFF]
--       Build the Parquet examples. Requires static libraries to be built.
--   PARQUET_REQUIRE_ENCRYPTION=OFF [default=OFF]
--       Build support for encryption. Fail if OpenSSL is not found
-- Gandiva options:
--   ARROW_GANDIVA_JAVA=OFF [default=OFF]
--       Build the Gandiva JNI wrappers
--   ARROW_GANDIVA_STATIC_LIBSTDCPP=OFF [default=OFF]
--       Include -static-libstdc++ -static-libgcc when linking with
--       Gandiva static libraries
--   ARROW_GANDIVA_PC_CXX_FLAGS="" [default=""]
--       Compiler flags to append when pre-compiling Gandiva operations
-- Advanced developer options:
--   ARROW_EXTRA_ERROR_CONTEXT=OFF [default=OFF]
--       Compile with extra error context (line numbers, code)
--   ARROW_OPTIONAL_INSTALL=OFF [default=OFF]
--       If enabled install ONLY targets that have already been built. Please be
--       advised that if this is enabled 'install' will fail silently on components
--       that have not been built
--   Outputting build configuration summary to /tmp/RtmpRLVXZh/file20721bb0e480/cmake_summary.json
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/RtmpRLVXZh/file20721bb0e480

/usr/bin/cmake --build . --target install
Scanning dependencies of target jemalloc_ep
Scanning dependencies of target mimalloc_ep
[  0%] Creating directories for 'mimalloc_ep'
[  1%] Creating directories for 'jemalloc_ep'
[  2%] Performing download step (download, verify and extract) for 'mimalloc_ep'
[  2%] Performing download step (download, verify and extract) for 'jemalloc_ep'
-- Downloading...
dst='/tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep-prefix/src/v1.7.3.tar.gz'
timeout='none'
-- Using src='https://github.com/microsoft/mimalloc/archive/v1.7.3.tar.gz'
-- [download 100% complete]
-- jemalloc_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/jemalloc_ep-prefix/src/jemalloc_ep-stamp/jemalloc_ep-download-*.log
[  2%] Performing patch step for 'jemalloc_ep'
[  2%] No update step for 'jemalloc_ep'
-- verifying file...
file='/tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep-prefix/src/v1.7.3.tar.gz'
-- Downloading... done
[  3%] Performing configure step for 'jemalloc_ep'
-- extracting...
src='/tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep-prefix/src/v1.7.3.tar.gz'
dst='/tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep-prefix/src/mimalloc_ep'
-- extracting... [tar xfz]
-- extracting... [analysis]
-- extracting... [rename]
-- extracting... [clean up]
-- extracting... done
[  3%] No patch step for 'mimalloc_ep'
[  3%] No update step for 'mimalloc_ep'
[  3%] Performing configure step for 'mimalloc_ep'
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
--
--
-- Library base name: mimalloc
-- Version          : 1.7
-- Build type       : release
-- C Compiler       : /usr/bin/gcc
-- Compiler flags   : -Wall;-Wextra;-Wno-unknown-pragmas;-fvisibility=hidden;-Wstrict-prototypes;-Wno-invalid-memory-model;-ftls-model=local-dynamic
-- Build targets    : static
--
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_EXPORT_NO_PACKAGE_REGISTRY
CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY

-- Build files have been written to: /tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep-prefix/src/mimalloc_ep-build
[  4%] Performing build step for 'mimalloc_ep'
Scanning dependencies of target mimalloc-static
[  6%] Building C object CMakeFiles/mimalloc-static.dir/src/stats.c.o
[ 13%] Building C object CMakeFiles/mimalloc-static.dir/src/random.c.o
[ 20%] Building C object CMakeFiles/mimalloc-static.dir/src/os.c.o
[ 26%] Building C object CMakeFiles/mimalloc-static.dir/src/bitmap.c.o
[ 33%] Building C object CMakeFiles/mimalloc-static.dir/src/arena.c.o
[ 40%] Building C object CMakeFiles/mimalloc-static.dir/src/region.c.o
[ 46%] Building C object CMakeFiles/mimalloc-static.dir/src/segment.c.o
[ 53%] Building C object CMakeFiles/mimalloc-static.dir/src/page.c.o
[ 60%] Building C object CMakeFiles/mimalloc-static.dir/src/alloc.c.o
[ 66%] Building C object CMakeFiles/mimalloc-static.dir/src/alloc-aligned.c.o
[ 73%] Building C object CMakeFiles/mimalloc-static.dir/src/alloc-posix.c.o
[ 80%] Building C object CMakeFiles/mimalloc-static.dir/src/heap.c.o
[ 86%] Building C object CMakeFiles/mimalloc-static.dir/src/options.c.o
[ 93%] Building C object CMakeFiles/mimalloc-static.dir/src/init.c.o
[100%] Linking C static library libmimalloc.a
[100%] Built target mimalloc-static
[  4%] Performing install step for 'mimalloc_ep'
[100%] Built target mimalloc-static
Install the project...
-- Install configuration: "RELEASE"
-- Installing: /tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep/src/mimalloc_ep/lib/mimalloc-1.7/libmimalloc.a
-- Installing: /tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep/src/mimalloc_ep/include/mimalloc-1.7/mimalloc.h
-- Installing: /tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep/src/mimalloc_ep/include/mimalloc-1.7/mimalloc-override.h
-- Installing: /tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep/src/mimalloc_ep/include/mimalloc-1.7/mimalloc-new-delete.h
-- Installing: /tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep/src/mimalloc_ep/share/mimalloc-1.7/cmake/mimalloc-config.cmake
-- Installing: /tmp/RtmpRLVXZh/file20721bb0e480/mimalloc_ep/src/mimalloc_ep/share/mimalloc-1.7/cmake/mimalloc-config-version.cmake
[  4%] Completed 'mimalloc_ep'
[  4%] Built target mimalloc_ep
Scanning dependencies of target aws_c_common_ep
[  4%] Creating directories for 'aws_c_common_ep'
[  4%] Performing download step (download, verify and extract) for 'aws_c_common_ep'
-- aws_c_common_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_common_ep-prefix/src/aws_c_common_ep-stamp/aws_c_common_ep-download-.log
[  4%] No patch step for 'aws_c_common_ep'
[  5%] No update step for 'aws_c_common_ep'
[  5%] Performing configure step for 'aws_c_common_ep'
-- jemalloc_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/jemalloc_ep-prefix/src/jemalloc_ep-stamp/jemalloc_ep-configure-.log
[  5%] Performing build step for 'jemalloc_ep'
-- aws_c_common_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_common_ep-prefix/src/aws_c_common_ep-stamp/aws_c_common_ep-configure-.log
[  5%] Performing build step for 'aws_c_common_ep'
-- aws_c_common_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_common_ep-prefix/src/aws_c_common_ep-stamp/aws_c_common_ep-build-.log
[  5%] Performing install step for 'aws_c_common_ep'
-- aws_c_common_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_common_ep-prefix/src/aws_c_common_ep-stamp/aws_c_common_ep-install-.log
[  6%] Completed 'aws_c_common_ep'
[  6%] Built target aws_c_common_ep
Scanning dependencies of target zlib_ep
[  6%] Creating directories for 'zlib_ep'
[  7%] Performing download step (download, verify and extract) for 'zlib_ep'
-- zlib_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-download-.log
[  7%] No patch step for 'zlib_ep'
[  7%] No update step for 'zlib_ep'
[  7%] Performing configure step for 'zlib_ep'
-- zlib_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-configure-.log
[  8%] Performing build step for 'zlib_ep'
-- zlib_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-build-.log
[  8%] Performing install step for 'zlib_ep'
-- zlib_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zlib_ep-prefix/src/zlib_ep-stamp/zlib_ep-install-.log
[  8%] Completed 'zlib_ep'
[  8%] Built target zlib_ep
Scanning dependencies of target brotli_ep
[  9%] Creating directories for 'brotli_ep'
[  9%] Performing download step (download, verify and extract) for 'brotli_ep'
-- brotli_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/brotli_ep-prefix/src/brotli_ep-stamp/brotli_ep-download-.log
[  9%] No patch step for 'brotli_ep'
[  9%] No update step for 'brotli_ep'
[ 10%] Performing configure step for 'brotli_ep'
-- brotli_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/brotli_ep-prefix/src/brotli_ep-stamp/brotli_ep-configure-.log
[ 10%] Performing build step for 'brotli_ep'
-- brotli_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/brotli_ep-prefix/src/brotli_ep-stamp/brotli_ep-build-.log
[ 10%] Performing install step for 'brotli_ep'
-- brotli_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/brotli_ep-prefix/src/brotli_ep-stamp/brotli_ep-install-.log
[ 10%] Completed 'brotli_ep'
[ 10%] Built target brotli_ep
Scanning dependencies of target snappy_ep
[ 11%] Creating directories for 'snappy_ep'
[ 11%] Performing download step (download, verify and extract) for 'snappy_ep'
-- snappy_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/snappy_ep-prefix/src/snappy_ep-stamp/snappy_ep-download-.log
[ 11%] No patch step for 'snappy_ep'
[ 11%] No update step for 'snappy_ep'
[ 12%] Performing configure step for 'snappy_ep'
-- snappy_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/snappy_ep-prefix/src/snappy_ep-stamp/snappy_ep-configure-.log
[ 12%] Performing build step for 'snappy_ep'
-- jemalloc_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/jemalloc_ep-prefix/src/jemalloc_ep-stamp/jemalloc_ep-build-.log
[ 12%] Performing install step for 'jemalloc_ep'
-- jemalloc_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/jemalloc_ep-prefix/src/jemalloc_ep-stamp/jemalloc_ep-install-.log
[ 12%] Completed 'jemalloc_ep'
[ 12%] Built target jemalloc_ep
Scanning dependencies of target boost_ep
[ 12%] Creating directories for 'boost_ep'
[ 12%] Performing download step (download, verify and extract) for 'boost_ep'
-- snappy_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/snappy_ep-prefix/src/snappy_ep-stamp/snappy_ep-build-.log
[ 12%] Performing install step for 'snappy_ep'
-- snappy_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/snappy_ep-prefix/src/snappy_ep-stamp/snappy_ep-install-.log
[ 12%] Completed 'snappy_ep'
[ 12%] Built target snappy_ep
Scanning dependencies of target zstd_ep
[ 12%] Creating directories for 'zstd_ep'
[ 13%] Performing download step (download, verify and extract) for 'zstd_ep'
-- zstd_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zstd_ep-prefix/src/zstd_ep-stamp/zstd_ep-download-.log
[ 13%] No patch step for 'zstd_ep'
[ 13%] No update step for 'zstd_ep'
[ 13%] Performing configure step for 'zstd_ep'
-- boost_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/boost_ep-prefix/src/boost_ep-stamp/boost_ep-download-.log
[ 14%] No patch step for 'boost_ep'
[ 14%] No update step for 'boost_ep'
[ 14%] No configure step for 'boost_ep'
[ 14%] No build step for 'boost_ep'
[ 15%] No install step for 'boost_ep'
[ 15%] Completed 'boost_ep'
[ 15%] Built target boost_ep
Scanning dependencies of target xsimd_ep
[ 15%] Creating directories for 'xsimd_ep'
[ 16%] Performing download step (download, verify and extract) for 'xsimd_ep'
-- xsimd_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/xsimd_ep-stamp/xsimd_ep-download-.log
[ 16%] No patch step for 'xsimd_ep'
[ 16%] No update step for 'xsimd_ep'
[ 16%] Performing configure step for 'xsimd_ep'
-- zstd_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zstd_ep-prefix/src/zstd_ep-stamp/zstd_ep-configure-.log
[ 17%] Performing build step for 'zstd_ep'
-- xsimd_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/xsimd_ep-stamp/xsimd_ep-configure-.log
[ 18%] Performing build step for 'xsimd_ep'
-- xsimd_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/xsimd_ep-stamp/xsimd_ep-build-.log
[ 18%] Performing install step for 'xsimd_ep'
-- xsimd_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/xsimd_ep-stamp/xsimd_ep-install-.log
[ 18%] Completed 'xsimd_ep'
[ 18%] Built target xsimd_ep
Scanning dependencies of target lz4_ep
[ 19%] Creating directories for 'lz4_ep'
[ 19%] Performing download step (download, verify and extract) for 'lz4_ep'
-- lz4_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/lz4_ep-prefix/src/lz4_ep-stamp/lz4_ep-download-.log
[ 19%] No patch step for 'lz4_ep'
[ 19%] Performing update step for 'lz4_ep'
[ 19%] No configure step for 'lz4_ep'
[ 20%] Performing build step for 'lz4_ep'
-- lz4_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/lz4_ep-prefix/src/lz4_ep-stamp/lz4_ep-build-.log
[ 20%] No install step for 'lz4_ep'
[ 20%] Completed 'lz4_ep'
[ 20%] Built target lz4_ep
Scanning dependencies of target bzip2_ep
[ 21%] Creating directories for 'bzip2_ep'
[ 21%] Performing download step (download, verify and extract) for 'bzip2_ep'
-- bzip2_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/bzip2_ep-prefix/src/bzip2_ep-stamp/bzip2_ep-download-.log
[ 21%] No patch step for 'bzip2_ep'
[ 21%] No update step for 'bzip2_ep'
[ 22%] No configure step for 'bzip2_ep'
[ 22%] Performing build step for 'bzip2_ep'
-- bzip2_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/bzip2_ep-prefix/src/bzip2_ep-stamp/bzip2_ep-build-.log
[ 22%] Performing install step for 'bzip2_ep'
-- bzip2_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/bzip2_ep-prefix/src/bzip2_ep-stamp/bzip2_ep-install-.log
[ 22%] Completed 'bzip2_ep'
[ 22%] Built target bzip2_ep
Scanning dependencies of target re2_ep
[ 23%] Creating directories for 're2_ep'
[ 23%] Performing download step (download, verify and extract) for 're2_ep'
-- re2_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/re2_ep-prefix/src/re2_ep-stamp/re2_ep-download-.log
[ 23%] No patch step for 're2_ep'
[ 23%] No update step for 're2_ep'
[ 24%] Performing configure step for 're2_ep'
-- re2_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/re2_ep-prefix/src/re2_ep-stamp/re2_ep-configure-.log
[ 24%] Performing build step for 're2_ep'
-- zstd_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zstd_ep-prefix/src/zstd_ep-stamp/zstd_ep-build-.log
[ 24%] Performing install step for 'zstd_ep'
-- zstd_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/zstd_ep-prefix/src/zstd_ep-stamp/zstd_ep-install-.log
[ 24%] Completed 'zstd_ep'
[ 24%] Built target zstd_ep
Scanning dependencies of target rapidjson_ep
[ 24%] Creating directories for 'rapidjson_ep'
[ 24%] Performing download step (download, verify and extract) for 'rapidjson_ep'
-- rapidjson_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/rapidjson_ep-stamp/rapidjson_ep-download-.log
[ 25%] No patch step for 'rapidjson_ep'
[ 25%] No update step for 'rapidjson_ep'
[ 25%] Performing configure step for 'rapidjson_ep'
-- rapidjson_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/rapidjson_ep-stamp/rapidjson_ep-configure-.log
[ 25%] Performing build step for 'rapidjson_ep'
-- rapidjson_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/rapidjson_ep-stamp/rapidjson_ep-build-.log
[ 26%] Performing install step for 'rapidjson_ep'
-- rapidjson_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/src/rapidjson_ep-stamp/rapidjson_ep-install-.log
[ 26%] Completed 'rapidjson_ep'
[ 26%] Built target rapidjson_ep
Scanning dependencies of target utf8proc_ep
[ 27%] Creating directories for 'utf8proc_ep'
[ 27%] Performing download step (download, verify and extract) for 'utf8proc_ep'
-- utf8proc_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/utf8proc_ep-prefix/src/utf8proc_ep-stamp/utf8proc_ep-download-.log
[ 27%] No patch step for 'utf8proc_ep'
[ 27%] No update step for 'utf8proc_ep'
[ 27%] Performing configure step for 'utf8proc_ep'
-- utf8proc_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/utf8proc_ep-prefix/src/utf8proc_ep-stamp/utf8proc_ep-configure-.log
[ 28%] Performing build step for 'utf8proc_ep'
-- utf8proc_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/utf8proc_ep-prefix/src/utf8proc_ep-stamp/utf8proc_ep-build-.log
[ 28%] Performing install step for 'utf8proc_ep'
-- utf8proc_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/utf8proc_ep-prefix/src/utf8proc_ep-stamp/utf8proc_ep-install-.log
[ 28%] Completed 'utf8proc_ep'
[ 28%] Built target utf8proc_ep
Scanning dependencies of target aws_checksums_ep
[ 28%] Creating directories for 'aws_checksums_ep'
[ 28%] Performing download step (download, verify and extract) for 'aws_checksums_ep'
-- aws_checksums_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_checksums_ep-prefix/src/aws_checksums_ep-stamp/aws_checksums_ep-download-.log
[ 29%] No patch step for 'aws_checksums_ep'
[ 29%] No update step for 'aws_checksums_ep'
[ 29%] Performing configure step for 'aws_checksums_ep'
-- aws_checksums_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_checksums_ep-prefix/src/aws_checksums_ep-stamp/aws_checksums_ep-configure-.log
[ 29%] Performing build step for 'aws_checksums_ep'
-- aws_checksums_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_checksums_ep-prefix/src/aws_checksums_ep-stamp/aws_checksums_ep-build-.log
[ 30%] Performing install step for 'aws_checksums_ep'
-- aws_checksums_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_checksums_ep-prefix/src/aws_checksums_ep-stamp/aws_checksums_ep-install-.log
[ 30%] Completed 'aws_checksums_ep'
[ 30%] Built target aws_checksums_ep
Scanning dependencies of target thrift_ep
[ 31%] Creating directories for 'thrift_ep'
[ 31%] Performing download step (download, verify and extract) for 'thrift_ep'
-- thrift_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/thrift_ep-prefix/src/thrift_ep-stamp/thrift_ep-download-.log
[ 31%] No patch step for 'thrift_ep'
[ 31%] No update step for 'thrift_ep'
[ 32%] Performing configure step for 'thrift_ep'
-- thrift_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/thrift_ep-prefix/src/thrift_ep-stamp/thrift_ep-configure-.log
[ 32%] Performing build step for 'thrift_ep'
-- re2_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/re2_ep-prefix/src/re2_ep-stamp/re2_ep-build-.log
[ 32%] Performing install step for 're2_ep'
-- re2_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/re2_ep-prefix/src/re2_ep-stamp/re2_ep-install-.log
[ 32%] Completed 're2_ep'
[ 32%] Built target re2_ep
Scanning dependencies of target aws_c_event_stream_ep
[ 32%] Creating directories for 'aws_c_event_stream_ep'
[ 32%] Performing download step (download, verify and extract) for 'aws_c_event_stream_ep'
-- aws_c_event_stream_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_event_stream_ep-prefix/src/aws_c_event_stream_ep-stamp/aws_c_event_stream_ep-download-.log
[ 32%] No patch step for 'aws_c_event_stream_ep'
[ 33%] No update step for 'aws_c_event_stream_ep'
[ 33%] Performing configure step for 'aws_c_event_stream_ep'
-- thrift_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/thrift_ep-prefix/src/thrift_ep-stamp/thrift_ep-build-.log
[ 33%] Performing install step for 'thrift_ep'
-- thrift_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/thrift_ep-prefix/src/thrift_ep-stamp/thrift_ep-install-.log
[ 33%] Completed 'thrift_ep'
[ 33%] Built target thrift_ep
-- aws_c_event_stream_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_event_stream_ep-prefix/src/aws_c_event_stream_ep-stamp/aws_c_event_stream_ep-configure-.log
[ 33%] Performing build step for 'aws_c_event_stream_ep'
-- aws_c_event_stream_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_event_stream_ep-prefix/src/aws_c_event_stream_ep-stamp/aws_c_event_stream_ep-build-.log
[ 33%] Performing install step for 'aws_c_event_stream_ep'
-- aws_c_event_stream_ep install command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/aws_c_event_stream_ep-prefix/src/aws_c_event_stream_ep-stamp/aws_c_event_stream_ep-install-.log
[ 34%] Completed 'aws_c_event_stream_ep'
[ 34%] Built target aws_c_event_stream_ep
Scanning dependencies of target awssdk_ep
[ 34%] Creating directories for 'awssdk_ep'
[ 34%] Performing download step (download, verify and extract) for 'awssdk_ep'
-- awssdk_ep download command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/awssdk_ep-prefix/src/awssdk_ep-stamp/awssdk_ep-download-.log
[ 34%] No update step for 'awssdk_ep'
[ 35%] No patch step for 'awssdk_ep'
[ 35%] Performing configure step for 'awssdk_ep'
-- awssdk_ep configure command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/awssdk_ep-prefix/src/awssdk_ep-stamp/awssdk_ep-configure-.log
[ 35%] Performing build step for 'awssdk_ep'
-- awssdk_ep build command succeeded.  See also /tmp/RtmpRLVXZh/file20721bb0e480/awssdk_ep-prefix/src/awssdk_ep-stamp/awssdk_ep-build-.log
[ 36%] Performing install step for 'awssdk_ep'
-- awssdk_ep install command succeeded.

Attaching package: ‘SparkR’
The following object is masked by ‘.GlobalEnv’:
setLocalProperty

The following objects are masked from ‘package:plyr’:
arrange, count, desc, join, mutate, rename, summarize, take

The following objects are masked from ‘package:data.table’:
between, cube, first, hour, last, like, minute, month, quarter,
rollup, second, tables, year

The following objects are masked from ‘package:stats’:
cov, filter, lag, na.omit, predict, sd, var, window

The following objects are masked from ‘package:base’:
as.data.frame, colnames, colnames<-, drop, endsWith, intersect,
rank, rbind, sample, startsWith, subset, summary, transform, union

[1] "installing arrow"
Installing package into ‘/local_disk0/.ephemeral_nfs/envs/rEnv-2e07b476-7186-45f2-b1ed-9eba706c1848’
(as ‘lib’ is unspecified)
trying URL 'https://packagemanager.rstudio.com/all/linux/focal/latest/src/contrib/arrow_7.0.0.tar.gz'
Content type 'binary/octet-stream' length 4572465 bytes (4.4 MB)
downloaded 4.4 MB
The downloaded source packages are in
‘/tmp/Rtmpt8TzRB/downloaded_packages’
Attaching package: ‘arrow’
The following objects are masked from ‘package:SparkR’:
contains, schema, struct

The following object is masked from ‘package:utils’:
timestamp`

@james-camacho-ab Please read my post above, you cannot install a binary package without setting the UserAgent.

If configured correctly, a binary installation will be performed instead of a source installation.

@eitsupi @wjones127 Here's where I'm at as of today:

Clusters are no longer able to install arrow via CRAN; the error provided is pretty vague and indicates reaching out to DBX Support, which I have but haven't heard back yet
I've tried adding the init script from this site, but the cluster gives a "non-zero value returned" error when trying to run it
I can put that script at the top of my notebook before the library installation, but the installation is taking ~17 minutes to complete. Here's some relevant logs from that installation:

* installing *source* package ‘arrow’ ...
** package ‘arrow’ successfully unpacked and MD5 sums checked
** using staged installation
**** pkg-config not installed, setting ARROW_DEPENDENCY_SOURCE=BUNDLED
trying URL 'https://github.com'
downloaded 203 KB

*** Using ubuntu-18.04 binary for ubuntu-20.04
trying URL 'https://arrow-r-nightly.s3.amazonaws.com/libarrow/bin/ubuntu-18.04/arrow-7.0.0.zip'
Error in download.file(from_url, to_file, quiet = quietly) :
  cannot open URL 'https://arrow-r-nightly.s3.amazonaws.com/libarrow/bin/ubuntu-18.04/arrow-7.0.0.zip'
*** No libarrow binary found for version 7.0.0 on ubuntu-18.04
*** Found local C++ source: 'tools/cpp'
*** Building libarrow from source
    For a faster, more complete installation, set the environment variable NOT_CRAN=true before installing
    See install vignette for details:
    https://cran.r-project.org/web/packages/arrow/vignettes/install.html

Note that NOT_CRAN = TRUE is set as an environment variable within the cluster, so not sure why that warning is popping up. Happy to try any other ideas or hop on a Zoom / Teams call to screen share and work through it

Happy to try any other ideas

You can try these approaches https://arrow.apache.org/docs/r/articles/install.html

@james-camacho-ab where you able to solve your install issue?

@assignUser Closing, not relevant for our team anymore since we no longer are using R. Seemed like it was a cluster policy issue


Unable to compile in Unity 4.3.7f1(attached screenshot of console errors)

I am unable to compile the code in Unity. I've attached a screenshot of the compile errors.

I'm running Unity v.4.3.7f1, so the first place I'd check is finding out what version of Unity you're using to build the project.

I'm using the UI features in 4.6. Thy are very necessary for the project.

Kind regards
Asbjørn Thirslund -
CEO, Brackeys
Links:
W: www.brackeys.com
Donate: www.brackeys.com/donate
YT: www.youtube.com/brackeys
FB: www.facebook.com/brackeys
Tw: www.twitter.com/BrackeysTweet
Contact:
E<EMAIL_ADDRESS>S: asbersej
T: +45 61711212

On 01/01/2015, at 18.00, Biochromatic<EMAIL_ADDRESS>wrote:
I am unable to compile the code in Unity. I've attached a screenshot of the compile errors.
I'm running Unity v.4.3.7f1, so the first place I'd check is finding out what version of Unity you're using to build the project.
—
Reply to this email directly or view it on GitHub.

I'm using the UI features in 4.6. Thy are very necessary for the project.

Kind regards
Asbjørn Thirslund -
CEO, Brackeys
Links:
W: www.brackeys.com
Donate: www.brackeys.com/donate
YT: www.youtube.com/brackeys
FB: www.facebook.com/brackeys
Tw: www.twitter.com/BrackeysTweet
Contact:
E<EMAIL_ADDRESS>S: asbersej
T: +45 61711212

On 01/01/2015, at 18.00, Biochromatic<EMAIL_ADDRESS>wrote:
I am unable to compile the code in Unity. I've attached a screenshot of the compile errors.
I'm running Unity v.4.3.7f1, so the first place I'd check is finding out what version of Unity you're using to build the project.
—
Reply to this email directly or view it on GitHub.


improve matching of implementation accuracy

cadquery and solidpython .stl output files are generally much bigger than trimesh. This is due to the different default accuracy settings.
Particularly,

'T-splinerev.stl' (trimesh): ~80kB
'C-splinerev.stl' (cadquery) : ~900kB
'S-splinerev.stl' (solidpython): ~200kB.

It can be seen by visual inspection that this is related to different accuracy on the output shape.
Similar differences are visible for 'rndrod'.
This results in an overall file size of the default output of:

trimesh: 2.2 MB
blender: 2.3MB
solidpython: 8.4MB
cadquery: 13.3MB

I think we should try to reduce accuracy for solidpython and cadquery.

this can now routinely be checked looking at test_report.csv and/or test_report.xlsx, following this commit https://github.com/bat52/pylele/commit/364168ce8f782649b1ac08a72c435254ecefa41d


Bribes

This PR completes the Trello task https://trello.com/c/Mz2cwwB7/37-track-penrose-lp-values
As well as including PEN transfers as part of Treasury Revenue. Not to mention a huge code clean-up!
@otterclamking this is ready for deployment, can be tested here: https://thegraph.com/hosted-service/subgraph/abtheo/otter-development?query=protocolMetrics
However, I will not close the branch yet. Still trying to figure out how to measure our Penrose vote allocation.

I can see a spike of Qi revenue on 3/7. Any idea why? @abtheo

I can see a spike of Qi revenue on 3/7 and make the graph not smooth. Any idea why? @abtheo

Yeah sorry I saw that just after I submitted the PR. The problem was my attempt at tracking Qi bribes:

The filter was too loose and checking for anyQi transfers from Deployer -> Treasury. So that spike was from us moving Qi between wallets (I think to lock it up) and accidentally got picked up as revenue.
This commit should have fixed the issue: https://github.com/OtterClam/otter-subgraph/pull/8/commits/45bfc49e2dd124a5d5cb1f9102eff1287983a8b7
But I can also re-deploy the test branch and wait for another sync if we wanna test more thoroughly 🙂

@otterclamking also spotted


fix: make wallet page the startpage for the options view

Describe the changes you have made in this PR
On the options.html page / currently redirects you to the websites.
Since we redirect users to / when switching accounts this takes you to the websites page.
I think it would be better to take users to the wallet page as it's probably the most commonly used one.

hmm. I am not sure about that.
We still show only the outgoing transactions from within Alby for example

I think the wallet just makes more sense here: from there users can access the most commonly used actions (send, receive, etc).
I can't imagine a situation where it would be more helpful to be taken to the websites than the wallet page when I switch accounts. (it's also the same behavior as in the popup)


Made the xrootd cache prefetch variable configurable via a pelican va…

…riable.
Added the Pelican variabled Cache.Prefix and used it to set the cache prefix value in the cache Changed its default from 20 to 0
Updated the xrootd config and cache templates accordingly

…riable.
Added the Pelican variabled Cache.Prefix and used it to set the cache prefix value in the cache Changed its default from 20 to 0 Updated the xrootd config and cache templates accordingly

Just clarifying before I review, is this supposed to be Cache.Prefix like the description claims or Cache.Prefetch like the title claims?

…riable.
Added the Pelican variabled Cache.Prefix and used it to set the cache prefix value in the cache Changed its default from 20 to 0 Updated the xrootd config and cache templates accordingly

Just clarifying before I review, is this supposed to be Cache.Prefix like the description claims or Cache.Prefetch like the title claims?

Prefetch, I had just been dealing with a lot of Prefix stuff and the typo just came out.
I recommend waiting until I can fix the test failures, though.


Fixed an error with broken ami message

This PR fixes issue #108

Coverage increased (+0.01%) to 91.945% when pulling ac692eb34c3618b97fb8e7d2ddaf3416f35722a9 on thomasvargiu:hotfix/108 into 61e58601c08731f754d21f5077000e034492f587 on marcelog:master.

Hello @thomasvargiu,
This is actually a bug in Asterisk, and should be fixed there. There are certainly a number of use cases where AMI is broken in different Asterisk versions and it doesn't make much sense to implement fixes for all of them.
Please see #61 and #108.
Best,

Hello @marcelog,
I think it's not the same error.
This is messages that I received from Asterisk:
Event: BridgeEnter
Privilege: call,all
BridgeUniqueid: 8fd6434d-3079-459e-9ee2-5aa69b63dd20
BridgeType: basic
BridgeTechnology: simple_bridge
BridgeCreator: <unknown>
BridgeName: <unknown>
BridgeNumChannels: 2
Channel: SIP/TRUNK-0017d8a2
ChannelState: 6
ChannelStateDesc: Up
CallerIDNum: xxxxxxxxxxx
CallerIDName: CID:xxxxxxxxxxx
ConnectedLineNum: xxxxxxxxxxx
ConnectedLineName: <unknown>
AccountCode:
Context: macro-dialout-trunk
Exten: s
Priority: 1
Uniqueid:<PHONE_NUMBER>.10133002

ame: CID:xxxxxxxxxxx
AccountCode:
Context: macro-dialout-trunk
Exten: s
Priority: 23
Uniqueid:<PHONE_NUMBER>.10132991
Variable: BRIDGEPEER
Value: SIP/TRUNK-0017d8a2

Event: VarSet
Privilege: dialplan,all
Channel: SIP/714-0017d8a0
ChannelState: 6
ChannelStateDesc: Up
CallerIDNum: xxxxxxxxxxx
CallerIDName: <unknown>
ConnectedLineNum: xxxxxxxxxxx
ConnectedLineName: CID:xxxxxxxxxxx
AccountCode:
Context: macro-dialout-trunk
Exten: s
Priority: 23
Uniqueid:<PHONE_NUMBER>.10132991
Variable: BRIDGEPVTCALLID
Value: 3555136e5da12f8e7e41aca324ba2eae@<IP_ADDRESS>:5060

You can see that an event is incomplete.
The problem is that it's a simple event, not related to an action. So the method findResponse() will return false and in the process() method we are not checking the value.
It's a simple unit test, if a method could return another value type, it should be tested and handled, like I did it in the PR.

Oh ok. But in any case, this is still a bug in Asterisk, right? If it is, I still think this should be fixed in Asterisk so we don't have to maintain these fixes.

Honestly I don't know if could be a bug in asterisk or could be caused by many many events in few milliseconds.
But trying to dispatch the event introduced a bug, so I think there are two options:

Don't dispatch an uncorrectly formatted message
Check if it's related to an action like I did in the PR

The error mentioned in issue #108 is a bug in the code, not in Asterisk, because we know that a function could return an object or false, but we are not checking it and we are considering it like it will return always an object.
What do you think?

It is considered to be an object to make it obvious that something went wrong. There should be no case where we get a response without an action id or a response for an action that we didn't send, so a crash is desired instead of continuing with invalid information.
I think more investigation is required before commiting code. My guess is that this is a bug in Asterisk, and that's why (and the reason explained above) I prefer not to merge this one.
If after some more research it turns out to be a PAMI code of course I'll be more than happy to merge a fix. But let's try no to commit code for a "just in case" scenario, or to compensate for Asterisk errors.
The AMI spec states that every message received should be an event or a response. In your tests you dispatch invalid AMI messages, this is not right and we should not encourage to support bad behaviors.

Ok, that's a perfect answer.
So the right way to refactor it should be throwing an Exception. But I think we could ignore it at the moment.
Thank you @marcelog

Thank you, @thomasvargiu! It's always good to have someone to discuss these matters 👍
Best!


⚠ Samsung has degraded performance

In 17cdf13, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2706 ms

Resolved: Samsung performance has improved in ed8635e.


Doesn't watch if the path dependency is the workspace root

Leptos-project: my-library/crates/website
workspace root: my-library
In the above case, if the leptos project has a path dependency on the workspace root, as in path = "../.." it will not be able to watch the files in the workspace root's src folder. This is because in this case unbase will give a "." path buf, which is then joined to src, yielding ./src as the path, which then fails the path prefix check for src/lib.rs
https://github.com/leptos-rs/cargo-leptos/blob/d36a1870452fceab2365df6ae16677b6573b69a3/src/ext/cargo.rs#L104-L106

PR: #304

Merged!


Design LTN tool - turn restriction editing: testing with complicated_turn_restictions required

Current behaviour
The LTN turn restriction display and editing features have had limited testing with complicated_turn_restictions. Hence the behaviour may be unspecified and counterintuitive.
Suggesting improvement
Add systematic tests that cover a meaningful range of scenarios involving complicated_turn_restictions.

Hi, currently working on sorting this out.

Hi, I'm working on this issue :)

Hi, I would like to take this issue up. As a beginner in Rust I believe this is a good opportunity for me. Kindly let me know.

Are you sure you understood what this issue entails? This is less about programming, more about design and testing (and automated testing in Rust is very much NOT a beginner thing)

Ooh, okay am currently working through the Rust Book and am on automation. With a little guidance I can try my hand. Ithought it was a good first issue. However, I see your point and admittedly I have not really looked into the issue in-depth,so let me leave it then.

Hi @iakev, feel free to take on this issue if it's interesting! But I would agree it's maybe a bit tougher to start with. If you wanted something much more focused -- without any UI code to wrangle with particularly -- I might suggest https://github.com/a-b-street/osm2streets/issues/222, if you have any interest in OpenStreetMap data. That issue requires some OSM domain knowledge, but we can also break down some steps if it's useful, so you could focus on the Rust part. It's a very easily unit testable issue, which is why it might be nice to start with.


Get rid of Webpack

Bundling WebAssembly with Webpack turns out to be ... complicated. It's easier for consumers if we just compile the TS to JS and let them worry about bundling.

Argh, trouble with this is that our tests run in Node and rely on WebPack running. Gonna see if I can find a workaround.

Hey @joshaber, I'm hoping this will go green. Node can't run the output of wasm-bindgen without running webpack on it, at least I couldn't make it work. So for the sake of the tests and also any other Node-based consumers of this library, I restored the use of webpack just for the main entry point. The web entry point continues to point at a version compiled directly with tsc as in your last commit. Will this work?

Ahh yeah that makes sense. Good catch @nathansobo 🤘
I had to update the lockfile but otherwise those changes look good to me 👍

Oops. I think the lockfile got lost in the shuffle. Thanks. Published this as 1.0.4


Samsungtv component don't work

The problem
None of the "buttons" works, i get a error when i press the volum up, down etc. in the samsungtv integration against my tv ue55d6300
Environment
0.104.3

Home Assistant release with the issue:
0.104.3
Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.):
Integration causing this issue:
samsungtv
Link to integration documentation on our website:
https://www.home-assistant.io/integrations/samsungtv/

Problem-relevant configuration.yaml
- platform: samsungtv
  host: <IP_ADDRESS>
  port: 55000
  mac: "e4:e0:c5:b3:6d:37"
  timeout: 3
  name: "TV"

Traceback/Error logs
The component raises a samsung_exceptions.AccessDenied
Additional information
I tried to debug the problem and it seems my  tv don't like any dots in the id. This might be a tv issue or upstream in samsungctrl, but since there no way to change the id in the config (removing dots fixes the issue) For now i have "solved" my problem by making a custom component where the only change is that there is not . in the id.

@Hellowlol is this still an issue?

Closing this issue due to recent inactivity, if you still experience issues feel free to comment on #31252.


CMIP5 data missing to run recipes and not available on ESGF nodes

Describe the bug
The recipe test runs done before the v2.4 release showed that quite a few recipes do not run because of missing CMIP5 data (see second table in this comment). Not only the data are not found on the default Mistral CMIP5 directory, but also the data are not found on any ESGF node when using the newly added automatic data download. This is preventing us from running the recipes and detecting potential issues arising after the data retrieval task.
Analyzing the log files from the v2.4 tests, I tried to compiled a list of missing datafiles for each recipe:

[x] recipe_anav13jclim.yml --> @schlunma: can still be downloaded manually

cVeg_Lmon_inmcm4_historical_r1i1p1*.nc
cSoil_Lmon_inmcm4_historical_r1i1p1*.nc

[ ] recipe_collins13ipcc.yml

tas_Amon_CESM1-CAM5-1-FV2_historical_r1i1p1*.nc
areacello_fx_bcc-csm1-1-m_historical_r0i0p0*.nc
areacello_fx_bcc-csm1-1-m_rcp85_r0i0p0*.nc
areacello_fx_inmcm4_historical_r0i0p0*.nc
areacello_fx_inmcm4_historical_r0i0p0*.nc

[ ] recipe_flato13ipcc.yml

areacello_fx_bcc-csm1-1-m_historical_r0i0p0*.nc
areacello_fx_inmcm4_historical_r0i0p0*.nc

[ ] recipe_landcover.yml

baresoilFrac_Lmon_inmcm4_rcp85_r1i1p1*.nc
grassFrac_Lmon_inmcm4_rcp85_r1i1p1*.nc
treeFrac_Lmon_inmcm4_rcp85_r1i1p1*.nc
shrubFrac_Lmon_inmcm4_rcp85_r1i1p1*.nc
cropFrac_Lmon_inmcm4_rcp85_r1i1p1*.nc

[ ] recipe_perfmetrics_CMIP5.yml

tas_Amon_CESM1-CAM5-1-FV2_historical_r1i1p1*.nc

[ ] recipe_perfmetrics_CMIP5_4cds.yml

tas_Amon_CESM1-CAM5-1-FV2_historical_r1i1p1*.nc

[ ] recipe_perfmetrics_land_CMIP5.yml

fgco2_Omon_BNU-ESM_historical_r1i1p1*.nc

[x] recipe_schlund20jgr_gpp_abs_rcp85.yml --> @schlunma: has been retracted, but recipe tested successfully with this data

co2_Amon_HadGEM2-ES_esmHistorical_r1i1p1*.nc
co2_Amon_HadGEM2-ES_esmrcp85_r1i1p1*.nc

[x] recipe_schlund20jgr_gpp_change_1pct.yml --> @schlunma: has been retracted, but recipe tested successfully with this data

co2_Amon_HadGEM2-ES_esmHistorical_r1i1p1*.nc
co2_Amon_HadGEM2-ES_esmrcp85_r1i1p1*.nc
gpp_Lmon_MIROC-ESM_esmFixClim1_r1i1p1*.nc

[x] recipe_schlund20jgr_gpp_change_rcp85.yml --> @schlunma: has been retracted, but recipe tested successfully with this data

co2_Amon_HadGEM2-ES_esmHistorical_r1i1p1*.nc
co2_Amon_HadGEM2-ES_esmrcp85_r1i1p1*.nc

[ ] recipe_seaice.yml

areacello_fx_bcc-csm1-1-m_historical_r0i0p0*.nc
areacello_fx_inmcm4_historical_r0i0p0*.nc

[ ] recipe_wenzel14jgr.yml

nbp_Lmon_HadGEM2-ES_esmHistorical_r1i1p1*.nc

[x] recipe_wenzel16nat.yml --> @schlunma: has been retracted, but recipe tested successfully with this data

gpp_Lmon_MIROC-ESM_esmFixClim1_r1i1p1*.nc

[ ] recipe_williams09climdyn_CREM.yml

sic_day_CNRM-CM5_amip_r1i1p1*.nc
sic_day_MIROC5_amip_r1i1p1*.nc
sic_day_MPI-ESM-LR_amip_r1i1p1*.nc
sic_day_MRI-CGCM3_amip_r1i1p1*.nc

It would be great if @ESMValGroup/esmvaltool-recipe-maintainers could have a look at the list above for their recipes and tell us:

how the datafiles were originally obtained: available on HPC system? downloaded from ESGF nodes?
if possible, identify the reason why these datafiles are no longer available on EFGS node: data retracted? facet error on ESGF?
how shall the recipe be fixed: commenting the dataset out? using CMIP6 data instead?

Please feel free to open a dedicated issue to discuss how to fix a given recipe with missing data.

@remi-kazeroni Release v2.5 is approaching quickly (the feature freeze will be on 2022-02-21). Since this issue is marked for v2.5, could you briefly comment if you further intend to include this in the new release and/or if you are facing any problems with it? Thanks!!

If a datafile like tas_Amon_CESM1-CAM5-1-FV2_historical_r1i1p1*.nc cannot be found on ESGF and is also absent from the CEDA archive, can it be assumed that the file has been retracted?

It seems there is no CMIP5 data available from CESM on ESGF at all. Not sure what's going on...

Another thing on these missing CMIP5 data. I noticed that some datafiles are note found (or downloaded) by the automatic download feature because these are stored with another product than output1, namely output2 or output.
A good example is the missing data for recipe_anav13jclim (see table above). The two files can easily be downloaded on ESGF but are stored under product: output2. Looking at our developer config file, I see that no machine-specific entries (DKRZ, CEDA, ETHZ, ...) take the product into account except for ESGF. I wonder if we could improve the data coverage by taking this variety of product into account in our config files. But perhaps there is a reason to only consider output1. Would you know something @zklaus and @bouweandela?
In fact, I used CMIP5: [/mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output1, /mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output2] in my config-user file and realized that the missing data are already on Mistral:
/mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output2/INM/inmcm4/historical/mon/land/Lmon/r1i1p1/v20110323/cVeg/cVeg_Lmon_inmcm4_historical_r1i1p1_185001-200512.nc
/mnt/lustre01/work/kd0956/CMIP5/data/cmip5/output2/INM/inmcm4/historical/mon/land/Lmon/r1i1p1/v20110323/cSoil/cSoil_Lmon_inmcm4_historical_r1i1p1_185001-200512.nc
No need for an ESGF download in that case!

@bouweandela, to highlight one sentence from the quote above:

In some cases a continuous sequence of model data will be split between
“output1” and “output2” in order to facilitate archive management.

I.e. timeseries can be split across both. Can we handle that?

I am not fully convinced this is the best option. I would guess, people usually do not even know whether it's output1 or output2. Couldn't we implement something that looks (by default) first into output1 and if nothing is found then also checks output2?

I agree with @axel-lauer that users probably don't and shouldn't know which is which. Perhaps '*' is a better default?

In that case the default value should be changed to ['output1', 'output2'] in _recipe.py

In that case the default value should be changed to ['output1', 'output2'] in _recipe.py

I'm not sure I understand where that should be done in _recipe.py. I'm also a bit hesitant to make that change at this stage of the release because it's not clear to me that datafiles would only be used once if present in both output1 and output2.
Nevertheless, I gave the idea a try in extra_facets/cmip5-product.yml, replacing: product: output1 by product: ['output1', 'output2']. The recipe_anav13clim runs fine with that change. Files under output2 are downloaded by esgf-pyclient and read by the tool. So perhaps it is worth a try in the next round of recipe testing? Note that product: * and product: output* would not be supported.

You're right, I forgot i moved the default setting there in https://github.com/ESMValGroup/ESMValCore/pull/1259. The only downside of this change is that it will slow down looking for CMIP5 data on ESGF by a factor of 2, because two searches will now be done for every dataset.. This is not so easy to solve in a nice way

I see. In that case, I'm tempted to do that change locally and use it to test some of the recipes during the next round of testing. I'll focus on cases which repeatedly failed because of missing data. If I finally get the missing data, I can undo that local change.

The only downside of this change is that it will slow down looking for CMIP5 data on ESGF by a factor of 2, [...]

Are you sure about that? I thought it is possible to do that in one search, so I tried looking at the code and it seems to me that it handles lists of values for facets exactly like that. But I may be wrong. Do you have a pointer?

@bouweandela why not a last-resort implementation ie try a second pass only if nothing was found with output1? Of course I may be talking out of my rear side now, since I've not seen the actual code :grin:

@zklaus is right, it should be no problem at all. That's what you get when trying to debug from memory instead of by looking at the code.

Hehe, been there, done that, @bouweandela.
So then we agree that it's perfectly reasonable to do that change. @remi-kazeroni, since you already have it locally, are you up for making the PR?

Wow, we ticked all the boxes :tada: I think this can be closed once all PRs listed above are merged!!

Wow, we ticked all the boxes 🎉 I think this can be closed once all PRs listed above are merged!!

Yes, I'm very happy we've managed to fix the "missing CMIP5 issues". This will simplify the recipe testing for future releases. The only unfixed recipe is recipe_flato13ipcc but removing missing data should be done in #2156 or subsequent PRs.
This issue can be closed once #2578 and #2579 are merged 👍


Fancy Zone monitor settings not saved

Microsoft PowerToys version
0.72.0
Installation method
GitHub
Running as admin
No
Area(s) with issue?
FancyZones
Steps to reproduce
I have created two custom layouts for my monitors. However, after rebooting my machine I have to go in and reassign the laytouts to the monitors. It appears that both of them go back to the priority screen layout.
It appears to only happen on reboot. Throughout the day I will move my laptop to a meeting room where I have to connect to different montiors and when I return to my desk the proper layouts are still assigned to correct monitors.
✔ Expected Behavior
Expecting once I assign a layout to a screen it stays that way.
❌ Actual Behavior
After a restart I have to reassign the custom layouts to the proper monitors.
Other Software
No response

/dup https://github.com/microsoft/PowerToys/issues/24656


Add CHANGELOG.md and danger Github action

As mentioned in the developer meeting, I will update CHANGELOG.md and Danger check to main code base to remind contributors to update CHANGELOG every time the PR is submitted. We can use CHANGELOG for release notes in the future.
Danger (https://github.com/danger/danger) will also check CHANGELOG and give warnings to test, anti-pattern, etc.

merged to development branch


The "View URL from Current Page" tooltip text is not clear

This is from #15941.
While I understand the feature, "View URL from Current Page" doesn't seem to explain it well.
Since this is a tooltip, I'd just explain the feature fully, even if it's going to be a long-ish tooltip.

Can I work on this @timvandermeij  ?? Please assign this to me if no one is working on it

Can you please check with the UX-team if we they think that we should tweak this string (again), or if this should be closed as WONTFIX, and if so what (exact) wording to use here?
/cc @calixteman, @marco-c

@ItielMaN Given https://github.com/mozilla/pdf.js/issues/15967#issuecomment-1547462757 do you have a specific suggestion in mind here?

I don't have a better idea other than #16419...

Can you properly explain the issue @ItielMaN @marco-c ?

Closing for now since the UX team looked into this not too long ago and provided the current wording, and the given suggestions don't make the intent of the functionality much more clear in my opinion as well.


timetracking: add compost bin time trackers

This adds compost timers to the farming plugin. I am only 99% sure of the tick cycles, the wiki is a very bad source of information and Mod Ash was unable to provide me a definitive answer. Per his tweets, he believes it is a 40 minute tick. I am very, very confident the timing of the supercompost for giant compost bins but less sure for regular bins. Wiki says the times differ, but this is not supported by what I have seen.
I AM confident there are two tick cycles for both giant and regular bins based on the varbits (two bits where the bin says the compost is rotting then a third bit where you can open the bin). There is a slight possibility that the regular bin is 2x20, but when I tested my plugin with that timing, the compost was never ready when the plugin said it would be.
This is the UI in the special tab of the plugin.

This closes #2960 #6569


Merkle path unbatch

This PR proposes an implementation of a into_paths method for BatchMerkleProof.
This method takes a batch proof and outputs the individual Merkle path proofs.

Thank you!


magic-vlsi: 8.3.465 -> 8.3.474

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/magic/versions.
meta.description for magic-vlsi is: VLSI layout tool written in Tcl
meta.homepage for magic-vlsi is: http://opencircuitdesign.com/magic/
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 8.3.466 with grep in /nix/store/dqdyaimmphpf42451iyjch6klng1c1mi-magic-vlsi-8.3.466
found 8.3.466 in filename of file in /nix/store/dqdyaimmphpf42451iyjch6klng1c1mi-magic-vlsi-8.3.466

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
magic-vlsi

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dqdyaimmphpf42451iyjch6klng1c1mi-magic-vlsi-8.3.466 \
  --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 magic-vlsi https://github.com/r-ryantm/nixpkgs/archive/2eaf114601e9c5b2135973ba16969d2715d53b21.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/2eaf114601e9c5b2135973ba16969d2715d53b21#magic-vlsi

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/dqdyaimmphpf42451iyjch6klng1c1mi-magic-vlsi-8.3.466
ls -la /nix/store/dqdyaimmphpf42451iyjch6klng1c1mi-magic-vlsi-8.3.466/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.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

magic-vlsi

Maintainer pings
cc @thoughtpolice @AndersonTorres for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/magic/versions.
meta.description for magic-vlsi is: VLSI layout tool written in Tcl
meta.homepage for magic-vlsi is: http://opencircuitdesign.com/magic/
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 8.3.474 with grep in /nix/store/pcy1gmnnlw1pg3j28phkz8fbkhp2b04v-magic-vlsi-8.3.474
found 8.3.474 in filename of file in /nix/store/pcy1gmnnlw1pg3j28phkz8fbkhp2b04v-magic-vlsi-8.3.474

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

magic-vlsi

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/pcy1gmnnlw1pg3j28phkz8fbkhp2b04v-magic-vlsi-8.3.474 \
  --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 magic-vlsi https://github.com/r-ryantm/nixpkgs/archive/42b132d9d0676f81c8b269a9b9216bfaf3feb393.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/42b132d9d0676f81c8b269a9b9216bfaf3feb393#magic-vlsi

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/pcy1gmnnlw1pg3j28phkz8fbkhp2b04v-magic-vlsi-8.3.474
ls -la /nix/store/pcy1gmnnlw1pg3j28phkz8fbkhp2b04v-magic-vlsi-8.3.474/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.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

magic-vlsi

Maintainer pings
cc @thoughtpolice @AndersonTorres for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/magic/versions.
meta.description for magic-vlsi is: VLSI layout tool written in Tcl
meta.homepage for magic-vlsi is: http://opencircuitdesign.com/magic/
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 8.3.478 with grep in /nix/store/xc8zrv3ssjlqlyx21rqcs7djj6mnk6a5-magic-vlsi-8.3.478
found 8.3.478 in filename of file in /nix/store/xc8zrv3ssjlqlyx21rqcs7djj6mnk6a5-magic-vlsi-8.3.478

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

magic-vlsi

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xc8zrv3ssjlqlyx21rqcs7djj6mnk6a5-magic-vlsi-8.3.478 \
  --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 magic-vlsi https://github.com/r-ryantm/nixpkgs/archive/0d98c898535da0ad0749c0d176e64e9fb389798c.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/0d98c898535da0ad0749c0d176e64e9fb389798c#magic-vlsi

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xc8zrv3ssjlqlyx21rqcs7djj6mnk6a5-magic-vlsi-8.3.478
ls -la /nix/store/xc8zrv3ssjlqlyx21rqcs7djj6mnk6a5-magic-vlsi-8.3.478/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.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

magic-vlsi

Maintainer pings
cc @thoughtpolice @AndersonTorres for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/magic/versions.
meta.description for magic-vlsi is: VLSI layout tool written in Tcl
meta.homepage for magic-vlsi is: http://opencircuitdesign.com/magic/
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 8.3.482 with grep in /nix/store/35b5a88k2xd6m6v6rvq7y17kpazhnfk0-magic-vlsi-8.3.482
found 8.3.482 in filename of file in /nix/store/35b5a88k2xd6m6v6rvq7y17kpazhnfk0-magic-vlsi-8.3.482

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

magic-vlsi

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/35b5a88k2xd6m6v6rvq7y17kpazhnfk0-magic-vlsi-8.3.482 \
  --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 magic-vlsi https://github.com/r-ryantm/nixpkgs/archive/f94682b16ca5b8204c7bce5627911c17950b8296.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/f94682b16ca5b8204c7bce5627911c17950b8296#magic-vlsi

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/35b5a88k2xd6m6v6rvq7y17kpazhnfk0-magic-vlsi-8.3.482
ls -la /nix/store/35b5a88k2xd6m6v6rvq7y17kpazhnfk0-magic-vlsi-8.3.482/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.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

magic-vlsi

Maintainer pings
cc @thoughtpolice @AndersonTorres for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/magic/versions.
meta.description for magic-vlsi is: VLSI layout tool written in Tcl
meta.homepage for magic-vlsi is: http://opencircuitdesign.com/magic/
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 8.3.483 with grep in /nix/store/vi5i6rpdg8p35fsk07lkidw08khqjksv-magic-vlsi-8.3.483
found 8.3.483 in filename of file in /nix/store/vi5i6rpdg8p35fsk07lkidw08khqjksv-magic-vlsi-8.3.483

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

magic-vlsi

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vi5i6rpdg8p35fsk07lkidw08khqjksv-magic-vlsi-8.3.483 \
  --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 magic-vlsi https://github.com/r-ryantm/nixpkgs/archive/22113879b2ab4cd508cb9aab0502c0c03dcf423f.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/22113879b2ab4cd508cb9aab0502c0c03dcf423f#magic-vlsi

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vi5i6rpdg8p35fsk07lkidw08khqjksv-magic-vlsi-8.3.483
ls -la /nix/store/vi5i6rpdg8p35fsk07lkidw08khqjksv-magic-vlsi-8.3.483/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.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

magic-vlsi

Maintainer pings
cc @thoughtpolice @AndersonTorres for testing.

@wegank can you test and send a log now?

It works!


nvmedit package doesn't recognize backup made from EZZee 500 series controller

Checklist

[X]  I am not using Home Assistant. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem is not mentioned there.

Deploy method
Manually built (git clone - npm run build - npm install
Z-Wave JS UI version
9.26.0
ZwaveJS version
13.10.3
Describe the bug
I have an EZZee 500 controller from Express Controls, Inc. FW is v2.8, SDK v6.8.0.
https://devices.zwave-js.io/?jumpTo=0x001e:0x0005:0x0002:0.0
The nvmedit package doesn't recognize it as valid.
To Reproduce
From UI, Advanced actions->NVM Management->Restore, select and submit backup file
or from command line, nvmedit.js 'convert' or 'nvm2json' operations.
Result from 'convert' operation is message
ZWaveError: Did not find a matching NVM 500 parser implementation! Make sure that the NVM data belongs to a controller with Z-Wave SDK 6.61 or higher. (ZW0280)
    at NVM500.init (/opt/zwave-js/node_modules/@zwave-js/nvmedit/build/lib/NVM500.js:58:19)
    at async nvm500ToJSON (/opt/zwave-js/node_modules/@zwave-js/nvmedit/build/convert.js:604:18)
    at async migrateNVM (/opt/zwave-js/node_modules/@zwave-js/nvmedit/build/convert.js:1289:23)
    at async Object.handler (/opt/zwave-js/node_modules/@zwave-js/nvmedit/build/cli.js:168:20) {
  code: 280,
  context: undefined,
  transactionSource: undefined
}

Expected behavior
From UI, successful restore to the same or different controller. From command line, successful conversion to binary or json output.
Additional context
I've dug into the nvmedit code and determined that it matches the Static_6_7x map and it's protocolVersion is 6.01. This protocolVersion is listed in the Static_6_8x map instead.
Patching build/lib/nvm500/impls/Static_6_7x.js, adding 6.01 to protocolVersions list allows the conversion to proceed further. It then fails with "NVM data for property ... not found" for four parameters that are absent in 6_7x vs. 6_8x. Patching build/convert.js, setting the adapter.get 'required' parameter to 'false' for these parameters allows the conversion to complete successfully.
Unless I missed something, these parameters being required will be an issue for any 6_7x or 6_6x NVM. Parameters absent in 6_7x are "systemState", "powerMode", "powerModeExtintEnable", "powerModeWutTimeout". Additional parameters absent in 6_6x are "powerLevelNormal" and "powerLevelLow".
Is it possible to accommodate this controller? I realize there would be issues if there are 6.01 controllers out there that match the 6_8x map. With my patches in place, a '... json2nvm --protocolVersion 6.01 ...' operation produces a 6_7x mapping vs. a 6_8x mapping without the patches.
FYI, EZZee of various revisions are used in the HomeSeer 'Z-Net' network enabled controllers
NVM backup file provided if requested.
Thanks

Is that SDK 6.8.0 or 6.80.0?

On Mon, Nov 11, 2024 at 2:12 AM AlCalzone @.***> wrote:

Is that SDK 6.8.0 or 6.80.0?
—
Reply to this email directly, view it on GitHub
https://github.com/zwave-js/node-zwave-js/issues/7385#issuecomment-2467755412,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYAS6B2MXP3LWCAQQFFXYL2AB7KPAVCNFSM6AAAAABRRJ4X4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRXG42TKNBRGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Sorry, it’s 6.81.0.

Here you go
zwave-js-ui-store.zip

I've tried to find a hint in the atrocious documentation (and some terrible C code) I have on this stuff, but there is no clear indication in which SDK/Protocol version the layout was changed. It's entirely possible that SDK 6.81.1 (protocol 6.02) is the first to switch to the 6.8x layout and SDK 6.81.0 still uses the 6.7x format.

So that NVM seems to have some odd format where the end of the NVM is in a different location than for most 6.7x NVMs.
With the linked PR, Z-Wave JS can now parse it, but I'm not sure if the controller will be able to work when restoring a different NVM onto it.

Great, thanks!
I noticed that extra space, 303 byte mystery offset in the "Application" module. I tried loading a file without the offset; the controller appeared to work; however the backup made from that had corruption in the next module and wouldn't pass the nvmedit parsing criteria.


Upgrade default flink version to 1.20.0

:mag: Description
Issue References 🔗

This pull request fixes #
Describe Your Solution 🔧
Upgrade default flink version to 1.20.0
Types of changes :bookmark:

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Behavior Without This Pull Request :coffin:
Behavior With This Pull Request :tada:
Related Unit Tests

Checklist 📝

[X] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

CI workflow should be updated too.

CI workflow should be updated too.

Changed, thanks

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (535c4f9) to head (e968502).

Additional details and impacted files
@@          Coverage Diff           @@
##           master   #6755   +/-   ##
======================================
  Coverage    0.00%   0.00%
======================================
  Files         684     684
  Lines       42288   42288
  Branches     5768    5768
======================================
  Misses      42288   42288

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Thanks, merged to master


Why not execute success callback instead of throw error if bundle is already defined?

The code is here:
https://github.com/muicss/loadjs/blob/b1795cf94a3429619c3dfe947fcb303c6d4e6b65/src/loadjs.js#L217-L224
This behavior looks so weird to me.
Is there any reason for doing this?

That code path is reached if a user tries to define a new bundle using an old name. If you want to add a new success callback to a previously-defined bundle you can use the .ready() method:
// define bundle and add a success callback
loadjs(['/file1.js', 'file2.js'], 'mybundle', function() {
  /* success-callback-1 */
});

// add a new success callback
loadjs.ready('mybundle', function() {
  /* success-callback-2 */
});

Got it :P


Allow single instance structs and null

Improve test coverage

@jnm2 In this PR I changed the locking code for single instance dependencies. Obviously I have no expectations for you to review this, but if you do have time to take a quick look at the (non-whitespace) changes to generator tests, that would be super appreciated, seeing how tricky this stuff is to get right.
Thanks!

The diff in GeneratorTests.cs looks like what I would do!

Amazing thanks!


Improve file system permissions

When using the instructions at https://github.com/Senzing/knowledge-base/blob/main/HOWTO/test-with-latest.md to install senzing and start the docker-compose, initializing the ConfigMgr gives

1007E|Database Connection Lost '(7:26000ERROR:  prepared statement "3587411181" does not exist )'.

The root cause is a file system permission issue that prevented the creation of the database schema.

Note that 775 did work.

Because of issues seen by customers, the permissions are initially set wide open ("777") so that the demonstrations work under all conditions.  It's the customer's responsibility to create a secure system.
These changes were made via:

https://github.com/Senzing/docker-compose-demo/issues/283
https://github.com/Senzing/docker-compose-demo/pull/289