Installation via pip fails for ROCm / AMD cards

Expected Behavior
I have a machine with and AMD GPU (Radeon RX 7900 XT). I tried to install this library as written in the README by running
CMAKE_ARGS="-DLLAMA_HIPBLAS=on" FORCE_CMAKE=1 pip install llama-cpp-python
Current Behavior
The installation fails, however when I simply run pip install llama-cpp-python it works
Environment and Context
To make the issue reproducible i made a Docker conatiner with this Dockerfile (adapted from the llama-cpp repo)
ARG UBUNTU_VERSION=22.04

# This needs to generally match the container host's environment.
ARG ROCM_VERSION=5.6however when I simply run pip install llama-cpp-python it works

# Target the CUDA build image
ARG BASE_ROCM_DEV_CONTAINER=rocm/dev-ubuntu-${UBUNTU_VERSION}:${ROCM_VERSION}-complete

FROM ${BASE_ROCM_DEV_CONTAINER} as build

# Unless otherwise specified, we make a fat build.
# List from https://github.com/ggerganov/llama.cpp/pull/1087#issuecomment-1682807878
# This is mostly tied to rocBLAS supported archs.
ARG ROCM_DOCKER_ARCH=\
    gfx803 \
    gfx900 \
    gfx906 \
    gfx908 \
    gfx90a \
    gfx1010 \
    gfx1030 \
    gfx1100 \ # this is my rocm arch
    gfx1101 \
    gfx1102

# Set nvcc architecture
ENV GPU_TARGETS=${ROCM_DOCKER_ARCH}
# Enable ROCm
ENV CC=/opt/rocm/llvm/bin/clang
ENV CXX=/opt/rocm/llvm/bin/clang++
ENV LLAMA_HIPBLAS=on

RUN apt-get update && apt-get -y install cmake protobuf-compiler aria2 git

System Info:
CPU: 13th Gen Intel(R) Core(TM) i5-13400F
GPU: Radeon RX 7900 XT
Ubuntu 22.04.1
Python 3.10.6
Make 4.3
g++ 11.3.0
Failure Information (for bugs)
The installation failed, here is the output when running CMAKE_ARGS="-DLLAMA_HIPBLAS=on" FORCE_CMAKE=1 pip install llama-cpp-python
root@8bebff5da3f1:/# CMAKE_ARGS="-DLLAMA_HIPBLAS=on" FORCE_CMAKE=1 pip install llama-cpp-python
Collecting llama-cpp-python
  Downloading llama_cpp_python-0.1.82.tar.gz (1.8 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 3.0 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: typing-extensions>=4.5.0 in /usr/local/lib/python3.10/dist-packages (from llama-cpp-python) (4.7.1)
Requirement already satisfied: numpy>=1.20.0 in /usr/local/lib/python3.10/dist-packages (from llama-cpp-python) (1.25.2)
Collecting diskcache>=5.6.1
  Downloading diskcache-5.6.1-py3-none-any.whl (45 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 45.6/45.6 KB 7.1 MB/s eta 0:00:00
Building wheels for collected packages: llama-cpp-python
  Building wheel for llama-cpp-python (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for llama-cpp-python (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [390 lines of output]

      --------------------------------------------------------------------------------
      -- Trying 'Ninja' generator
      --------------------------------
      ---------------------------
      ----------------------
      -----------------
      ------------
      -------
      --
      CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
        Compatibility with CMake < 3.5 will be removed from a future version of
        CMake.

        Update the VERSION argument <min> value or use a ...<max> suffix to tell
        CMake that the project does not need compatibility with older versions.

      Not searching for unused variables given on the command line.

      -- The C compiler identification is Clang 16.0.0
      -- Detecting C compiler ABI info
      -- Detecting C compiler ABI info - done
      -- Check for working C compiler: /opt/rocm/llvm/bin/clang - skipped
      -- Detecting C compile features
      -- Detecting C compile features - done
      -- The CXX compiler identification is Clang 16.0.0
      -- Detecting CXX compiler ABI info
      -- Detecting CXX compiler ABI info - done
      -- Check for working CXX compiler: /opt/rocm/llvm/bin/clang++ - skipped
      -- Detecting CXX compile features
      -- Detecting CXX compile features - done
      -- Configuring done (0.6s)
      -- Generating done (0.0s)
      -- Build files have been written to: /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/_cmake_test_compile/build
      --
      -------
      ------------
      -----------------
      ----------------------
      ---------------------------
      --------------------------------
      -- Trying 'Ninja' generator - success
      --------------------------------------------------------------------------------

      Configuring Project
        Working directory:
          /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/_skbuild/linux-x86_64-3.10/cmake-build
        Command:
          /tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/cmake/data/bin/cmake /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888 -G Ninja -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/ninja/data/bin/ninja --no-warn-unused-cli -DCMAKE_INSTALL_PREFIX:PATH=/tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/_skbuild/linux-x86_64-3.10/cmake-install -DPYTHON_VERSION_STRING:STRING=3.10.6 -DSKBUILD:INTERNAL=TRUE -DCMAKE_MODULE_PATH:PATH=/tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/skbuild/resources/cmake -DPYTHON_EXECUTABLE:PATH=/usr/bin/python3 -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.10 -DPython_EXECUTABLE:PATH=/usr/bin/python3 -DPython_ROOT_DIR:PATH=/usr -DPython_FIND_REGISTRY:STRING=NEVER -DPython_INCLUDE_DIR:PATH=/usr/include/python3.10 -DPython3_EXECUTABLE:PATH=/usr/bin/python3 -DPython3_ROOT_DIR:PATH=/usr -DPython3_FIND_REGISTRY:STRING=NEVER -DPython3_INCLUDE_DIR:PATH=/usr/include/python3.10 -DCMAKE_MAKE_PROGRAM:FILEPATH=/tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/ninja/data/bin/ninja -DLLAMA_HIPBLAS=on -DCMAKE_BUILD_TYPE:STRING=Release -DLLAMA_HIPBLAS=on

      Not searching for unused variables given on the command line.
      -- The C compiler identification is Clang 16.0.0
      -- The CXX compiler identification is Clang 16.0.0
      -- Detecting C compiler ABI info
      -- Detecting C compiler ABI info - done
      -- Check for working C compiler: /opt/rocm/llvm/bin/clang - skipped
      -- Detecting C compile features
      -- Detecting C compile features - done
      -- Detecting CXX compiler ABI info
      -- Detecting CXX compiler ABI info - done
      -- Check for working CXX compiler: /opt/rocm/llvm/bin/clang++ - skipped
      -- Detecting CXX compile features
      -- Detecting CXX compile features - done
      -- Found Git: /usr/bin/git (found version "2.34.1")
      fatal: not a git repository (or any of the parent directories): .git
      fatal: not a git repository (or any of the parent directories): .git
      CMake Warning at vendor/llama.cpp/CMakeLists.txt:118 (message):
        Git repository not found; to enable automatic generation of build info,
        make sure Git is installed and the project is a Git repository.

      -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
      -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
      -- Found Threads: TRUE
      CMake Deprecation Warning at /opt/rocm/lib/cmake/hip/hip-config.cmake:20 (cmake_minimum_required):
        Compatibility with CMake < 3.5 will be removed from a future version of
        CMake.

        Update the VERSION argument <min> value or use a ...<max> suffix to tell
        CMake that the project does not need compatibility with older versions.
      Call Stack (most recent call first):
        vendor/llama.cpp/CMakeLists.txt:366 (find_package)

      -- hip::amdhip64 is SHARED_LIBRARY
      -- Performing Test HIP_CLANG_SUPPORTS_PARALLEL_JOBS
      -- Performing Test HIP_CLANG_SUPPORTS_PARALLEL_JOBS - Success
      CMake Deprecation Warning at /opt/rocm/lib/cmake/hip/hip-config.cmake:20 (cmake_minimum_required):
        Compatibility with CMake < 3.5 will be removed from a future version of
        CMake.

        Update the VERSION argument <min> value or use a ...<max> suffix to tell
        CMake that the project does not need compatibility with older versions.
      Call Stack (most recent call first):
        /tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/cmake/data/share/cmake-3.27/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
        /opt/rocm/lib/cmake/hipblas/hipblas-config.cmake:90 (find_dependency)
        vendor/llama.cpp/CMakeLists.txt:367 (find_package)

      -- hip::amdhip64 is SHARED_LIBRARY
      -- HIP and hipBLAS found
      -- CMAKE_SYSTEM_PROCESSOR: x86_64
      -- x86 detected
      -- Configuring done (0.6s)
      -- Generating done (0.0s)
      -- Build files have been written to: /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/_skbuild/linux-x86_64-3.10/cmake-build
      [1/12] Building C object vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o
      [2/12] Building CXX object vendor/llama.cpp/common/CMakeFiles/common.dir/console.cpp.o
      [3/12] Building CXX object vendor/llama.cpp/common/CMakeFiles/common.dir/grammar-parser.cpp.o
      [4/12] Building C object vendor/llama.cpp/CMakeFiles/ggml.dir/k_quants.c.o
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/k_quants.c:186:11: warning: variable 'sum_x' set but not used [-Wunused-but-set-variable]
          float sum_x = 0;
                ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/k_quants.c:187:11: warning: variable 'sum_x2' set but not used [-Wunused-but-set-variable]
          float sum_x2 = 0;
                ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/k_quants.c:182:14: warning: unused function 'make_qkx1_quants' [-Wunused-function]
      static float make_qkx1_quants(int n, int nmax, const float * restrict x, uint8_t * restrict L, float * restrict the_min,
                   ^
      3 warnings generated.
      [5/12] Building CXX object vendor/llama.cpp/common/CMakeFiles/common.dir/common.cpp.o
      [6/12] Building C object vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:2413:5: warning: implicit conversion increases floating-point precision: 'float' to 'ggml_float' (aka 'double') [-Wdouble-promotion]
          GGML_F16_VEC_REDUCE(sumf, sum);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:2045:37: note: expanded from macro 'GGML_F16_VEC_REDUCE'
      #define GGML_F16_VEC_REDUCE         GGML_F32Cx8_REDUCE
                                          ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:2035:33: note: expanded from macro 'GGML_F32Cx8_REDUCE'
      #define GGML_F32Cx8_REDUCE      GGML_F32x8_REDUCE
                                      ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:1981:11: note: expanded from macro 'GGML_F32x8_REDUCE'
          res = _mm_cvtss_f32(_mm_hadd_ps(t1, t1));                     \
              ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:3456:9: warning: implicit conversion increases floating-point precision: 'float' to 'ggml_float' (aka 'double') [-Wdouble-promotion]
              GGML_F16_VEC_REDUCE(sumf[k], sum[k]);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:2045:37: note: expanded from macro 'GGML_F16_VEC_REDUCE'
      #define GGML_F16_VEC_REDUCE         GGML_F32Cx8_REDUCE
                                          ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:2035:33: note: expanded from macro 'GGML_F32Cx8_REDUCE'
      #define GGML_F32Cx8_REDUCE      GGML_F32x8_REDUCE
                                      ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:1981:11: note: expanded from macro 'GGML_F32x8_REDUCE'
          res = _mm_cvtss_f32(_mm_hadd_ps(t1, t1));                     \
              ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:596:23: warning: unused function 'mul_sum_i8_pairs' [-Wunused-function]
      static inline __m128i mul_sum_i8_pairs(const __m128i x, const __m128i y) {
                            ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:627:19: warning: unused function 'hsum_i32_4' [-Wunused-function]
      static inline int hsum_i32_4(const __m128i a) {
                        ^
      /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/vendor/llama.cpp/ggml.c:692:23: warning: unused function 'packNibbles' [-Wunused-function]
      static inline __m128i packNibbles( __m256i bytes )
                            ^
      5 warnings generated.
      [7/12] Linking C static library vendor/llama.cpp/libggml_static.a
      [8/12] Building CXX object vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o
      [9/12] Building CXX object vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      [10/12] Linking CXX shared library vendor/llama.cpp/libggml_shared.so
      FAILED: vendor/llama.cpp/libggml_shared.so
      : && /opt/rocm/llvm/bin/clang++ -fPIC -O3 -DNDEBUG   -shared -Wl,-soname,libggml_shared.so -o vendor/llama.cpp/libggml_shared.so vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o vendor/llama.cpp/CMakeFiles/ggml.dir/k_quants.c.o vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o  -Wl,-rpath,/opt/rocm-5.6.0/lib:/opt/rocm/lib:  --hip-link  --offload-arch=gfx900  --offload-arch=gfx906  --offload-arch=gfx908  --offload-arch=gfx90a  --offload-arch=gfx1030  /opt/rocm-5.6.0/lib/libhipblas.so.1.0.50600  /opt/rocm-5.6.0/lib/librocblas.so.3.0.50600  /opt/rocm-5.6.0/llvm/lib/clang/16.0.0/lib/linux/libclang_rt.builtins-x86_64.a  /opt/rocm/lib/libamdhip64.so.5.6.50600 && :
      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against symbol '__gxx_personality_v0'; recompile with -fPIC
      >>> defined in /usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(.eh_frame+0x7343)

      ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'stderr'; recompile with -fPIC
      >>> defined in /lib/x86_64-linux-gnu/libc.so.6
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(.eh_frame+0x7361)

      ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'stderr'; recompile with -fPIC
      >>> defined in /lib/x86_64-linux-gnu/libc.so.6
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(.eh_frame+0x7399)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)
      llama-cpp-python/vendor/llama.cpp$ git log | head -3
commit 66874d4fbcc7866377246efbcee938e8cc9c7d76
Author: Kerfuffle<EMAIL_ADDRESS>Date:   Thu May 25 20:18:01 2023 -0600
      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'stderr'; recompile with -fPIC
      >>> defined in /lib/x86_64-linux-gnu/libc.so.6
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
      clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
      [11/12] Linking CXX shared library vendor/llama.cpp/libllama.so
      FAILED: vendor/llama.cpp/libllama.so
      : && /opt/rocm/llvm/bin/clang++ -fPIC -O3 -DNDEBUG   -shared -Wl,-soname,libllama.so -o vendor/llama.cpp/libllama.so vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o vendor/llama.cpp/CMakeFiles/ggml.dir/k_quants.c.o vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o  -Wl,-rpath,/opt/rocm-5.6.0/lib:/opt/rocm/lib:  --hip-link  --offload-arch=gfx900  --offload-arch=gfx906  --offload-arch=gfx908  --offload-arch=gfx90a  --offload-arch=gfx1030  /opt/rocm-5.6.0/lib/libhipblas.so.1.0.50600  /opt/rocm-5.6.0/lib/librocblas.so.3.0.50600  /opt/rocm-5.6.0/llvm/lib/clang/16.0.0/lib/linux/libclang_rt.builtins-x86_64.a  /opt/rocm/lib/libamdhip64.so.5.6.50600 && :
      ld.lld: error: relocation R_X86_64_32 cannot be used against symbol '__gxx_personality_v0'; recompile with -fPIC
      >>> defined in /usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(.eh_frame+0x9E3F)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(.eh_frame+0x9E5D)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(.eh_frame+0x9E95)

      ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'stderr'; recompile with -fPIC
      >>> defined in /lib/x86_64-linux-gnu/libc.so.6
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'stderr'; recompile with -fPIC
      >>> defined in /lib/x86_64-linux-gnu/libc.so.6
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32S cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'stderr'; recompile with -fPIC
      >>> defined in /lib/x86_64-linux-gnu/libc.so.6
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
      clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
      ninja: build stopped: subcommand failed.
      Traceback (most recent call last):
        File "/tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/skbuild/setuptools_wrap.py", line 674, in setup
          cmkr.make(make_args, install_target=cmake_install_target, env=env)
        File "/tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/skbuild/cmaker.py", line 697, in make
          self.make_impl(clargs=clargs, config=config, source_dir=source_dir, install_target=install_target, env=env)
        File "/tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/skbuild/cmaker.py", line 742, in make_impl
          raise SKBuildError(msg)

      An error occurred while building with CMake.
        Command:
          /tmp/pip-build-env-_3ufrfgk/overlay/local/lib/python3.10/dist-packages/cmake/data/bin/cmake --build . --target install --config Release --
        Install target:
          install
        Source directory:
          /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888
        Working directory:
          /tmp/pip-install-wf4bikyh/llama-cpp-python_19efb6e7a69446cd9a7c7007cc342888/_skbuild/linux-x86_64-3.10/cmake-build
      Please check the install target is valid and see CMake's output for more information.

      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for llama-cpp-python
Failed to build llama-cpp-python
ERROR: Could not build wheels for llama-cpp-python, which is required to install pyproject.toml-based projects

As reference here is what happens when i simpy run pip install llama-cpp-python
pip install llama-cpp-python
Collecting llama-cpp-python
  Using cached llama_cpp_python-0.1.82.tar.gz (1.8 MB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: numpy>=1.20.0 in /usr/local/lib/python3.10/dist-packages (from llama-cpp-python) (1.25.2)
Collecting diskcache>=5.6.1
  Using cached diskcache-5.6.1-py3-none-any.whl (45 kB)
Requirement already satisfied: typing-extensions>=4.5.0 in /usr/local/lib/python3.10/dist-packages (from llama-cpp-python) (4.7.1)
Building wheels for collected packages: llama-cpp-python
  Building wheel for llama-cpp-python (pyproject.toml) ... done
  Created wheel for llama-cpp-python: filename=llama_cpp_python-0.1.82-cp310-cp310-linux_x86_64.whl size=593844 sha256=5523b29af1720e7931b4ca3caee8ebb65b502a8640db4f1e6a633eb7d444dff5
  Stored in directory: /root/.cache/pip/wheels/d5/5a/02/e3a3e540045da967de35d1ac2220a194e26e57b120bb46b466
Successfully built llama-cpp-python
Installing collected packages: diskcache, llama-cpp-python
Successfully installed diskcache-5.6.1 llama-cpp-python-0.1.82
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

After installation with this second method the code runs as expected and it utilizes the gpu
Steps to Reproduce
Make sure you have an AMD GPU

Build a docker container with the dockerfile written above docker build --pull --rm -f "Dockerfile" -t llama-cpp-python-container:latest
Run it docker run -it  --device=/dev/kfd --device=/dev/dri llama-cpp-python-container bash
try the two intallation methods CMAKE_ARGS="-DLLAMA_HIPBLAS=on" FORCE_CMAKE=1 pip install llama-cpp-python and pip install llama-cpp-python

Failure Logs
Environment info
llama-cpp-python$ pip list | egrep "uvicorn|fastapi|sse-starlette|numpy"
numpy              1.25.2

I'm not sure where to get the llama-cpp version

Also, if you want I could make a pull request that adds the docker container for AMD folks along with some instructions

@Francesco215 thanks for reporting this, looks like a llama.cpp linker error when building it as a shared library with the new ROCm support.
      [10/12] Linking CXX shared library vendor/llama.cpp/libggml_shared.so
      FAILED: vendor/llama.cpp/libggml_shared.so
      : && /opt/rocm/llvm/bin/clang++ -fPIC -O3 -DNDEBUG   -shared -Wl,-soname,libggml_shared.so -o vendor/llama.cpp/libggml_shared.so vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o vendor/llama.cpp/CMakeFiles/ggml.dir/k_quants.c.o vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o  -Wl,-rpath,/opt/rocm-5.6.0/lib:/opt/rocm/lib:  --hip-link  --offload-arch=gfx900  --offload-arch=gfx906  --offload-arch=gfx908  --offload-arch=gfx90a  --offload-arch=gfx1030  /opt/rocm-5.6.0/lib/libhipblas.so.1.0.50600  /opt/rocm-5.6.0/lib/librocblas.so.3.0.50600  /opt/rocm-5.6.0/llvm/lib/clang/16.0.0/lib/linux/libclang_rt.builtins-x86_64.a  /opt/rocm/lib/libamdhip64.so.5.6.50600 && :
      ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
      >>> defined in vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(ggml_init_cublas)

      ld.lld: error: relocation R_X86_64_32 cannot be used against symbol '__gxx_personality_v0'; recompile with -fPIC
      >>> defined in /usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so
      >>> referenced by ggml-cuda.cu
      >>>               vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o:(.eh_frame+0x7343)

Unfortunately I don't have an AMD card with ROCm support on hand so I can't contribute much more than pointing you in that direction.  I would try adding
if (BUILD_SHARED_LIBS)
    set_target_properties(ggml-rocm PROPERTIES POSITION_INDEPENDENT_CODE ON)
endif()

inside this section https://github.com/ggerganov/llama.cpp/blob/44c117f41ee01c5ac8fb86bba041f08d8b87b46d/CMakeLists.txt#L373
and see if that works.

@Francesco215 also yes would really appreciate that Docker image!

Unfortunately I don't have an AMD card with ROCm support on hand so I can't contribute much more than pointing you in that direction. I would try adding
if (BUILD_SHARED_LIBS)
    set_target_properties(ggml-rocm PROPERTIES POSITION_INDEPENDENT_CODE ON)
endif()

inside this section https://github.com/ggerganov/llama.cpp/blob/44c117f41ee01c5ac8fb86bba041f08d8b87b46d/CMakeLists.txt#L373
and see if that works.

Just here to confirm that this solves the problem. I was having the same issue trying to run on my 6800 XT (also through a rocm container) and, after changing the CmakeLists the way you suggested, llama.cpp uses the GPU through ROCm as expected:
llm_load_tensors: ggml ctx size =    0.12 MB
llm_load_tensors: using ROCm for GPU acceleration
llm_load_tensors: mem required  =  107.54 MB (+  400.00 MB per state)
llm_load_tensors: offloading 40 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloading v cache to GPU
llm_load_tensors: offloading k cache to GPU
llm_load_tensors: offloaded 43/43 layers to GPU
llm_load_tensors: VRAM used: 9095 MB

@Francesco215 you need to add the change after the "add_library" (line 373), otherwise CMake won't find the library.
It should be like this:
...
        add_library(ggml-rocm OBJECT ggml-cuda.cu ggml-cuda.h)
        if (BUILD_SHARED_LIBS)
            set_target_properties(ggml-rocm PROPERTIES POSITION_INDEPENDENT_CODE ON)
        endif()
....

About the container, I didn't have any problem, only difference is that a use rocm/rocm-terminal:latest. If it helps, here are my Dockerfile and install script.

I am struggling with this too. Unfortunately I can't view that linked Dockerfile or install script (404).

I followed the instructions here but trying to generate anything gives me this error:
CUDA error 98 at [...]/llama-cpp-python/vendor/llama.cpp/ggml-cuda.cu:6046: invalid device function
Am I doing something wrong?

@Francesco215 I got the PR merged with the fix in llama.cpp and it's now in 0.2.6

Thanks!

@Francesco215 can I close this up then?

My issue is not related to docker, but I've been using this and #695 as a guideline. I haven't been able to build the wheel.
I'm running into issues with building for AMD GPU as well when running the flag and decided to take a look at llama.cpp to see if I could isolate the issue.
I beginning to think this is not a llama-cpp-python issue at all.
I'm working on it and if I can find a solution, I'll most likely post to the AMD GPU thread for llama.cpp instead because I think it's out of scope.

I have a problem with the installation too.
I have ROCm 5.7 installed and python 3.10
llame.cpp (whitout python) I can build for ROCm, but the python version not.
`CMAKE_ARGS="-DLLAMA_HIPBLAS=on" FORCE_CMAKE=1 pip install llama-cpp-python
Collecting llama-cpp-python
Using cached llama_cpp_python-0.2.11.tar.gz (3.6 MB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Installing backend dependencies ... done
Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: typing-extensions>=4.5.0 in /home/voelskow/rocm/lib/python3.10/site-packages (from llama-cpp-python) (4.8.0)
Requirement already satisfied: numpy>=1.20.0 in /home/voelskow/rocm/lib/python3.10/site-packages (from llama-cpp-python) (1.24.0)
Requirement already satisfied: diskcache>=5.6.1 in /home/voelskow/rocm/lib/python3.10/site-packages (from llama-cpp-python) (5.6.3)
Building wheels for collected packages: llama-cpp-python
Building wheel for llama-cpp-python (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for llama-cpp-python (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [114 lines of output]
*** scikit-build-core 0.5.1 using CMake 3.27.6 (wheel)
*** Configuring CMake...
loading initial cache file /tmp/tmpzfkz647x/build/CMakeInit.txt
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.34.1")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
CMake Warning at vendor/llama.cpp/CMakeLists.txt:380 (message):
Only LLVM is supported for HIP, hint: CC=/opt/rocm/llvm/bin/clang
  CMake Warning at vendor/llama.cpp/CMakeLists.txt:383 (message):
    Only LLVM is supported for HIP, hint: CXX=/opt/rocm/llvm/bin/clang++

  CMake Deprecation Warning at /opt/rocm/lib/cmake/hip/hip-config.cmake:20 (cmake_minimum_required):
    Compatibility with CMake < 3.5 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.
  Call Stack (most recent call first):
    vendor/llama.cpp/CMakeLists.txt:386 (find_package)

  CMake Deprecation Warning at /opt/rocm/lib/cmake/hip/hip-config-amd.cmake:21 (cmake_minimum_required):
    Compatibility with CMake < 3.5 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.
  Call Stack (most recent call first):
    /opt/rocm/lib/cmake/hip/hip-config.cmake:150 (include)
    vendor/llama.cpp/CMakeLists.txt:386 (find_package)

  -- hip::amdhip64 is SHARED_LIBRARY
  -- /usr/bin/c++: CLANGRT compiler options not supported.
  CMake Deprecation Warning at /opt/rocm/lib/cmake/hip/hip-config.cmake:20 (cmake_minimum_required):
    Compatibility with CMake < 3.5 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.
  Call Stack (most recent call first):
    /tmp/pip-build-env-ltem499n/normal/lib/python3.10/site-packages/cmake/data/share/cmake-3.27/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
    /opt/rocm/lib/cmake/hipblas/hipblas-config.cmake:90 (find_dependency)
    vendor/llama.cpp/CMakeLists.txt:387 (find_package)

  CMake Deprecation Warning at /opt/rocm/lib/cmake/hip/hip-config-amd.cmake:21 (cmake_minimum_required):
    Compatibility with CMake < 3.5 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.
  Call Stack (most recent call first):
    /opt/rocm/lib/cmake/hip/hip-config.cmake:150 (include)
    /tmp/pip-build-env-ltem499n/normal/lib/python3.10/site-packages/cmake/data/share/cmake-3.27/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
    /opt/rocm/lib/cmake/hipblas/hipblas-config.cmake:90 (find_dependency)
    vendor/llama.cpp/CMakeLists.txt:387 (find_package)

  -- hip::amdhip64 is SHARED_LIBRARY
  -- /usr/bin/c++: CLANGRT compiler options not supported.
  -- HIP and hipBLAS found
  -- CMAKE_SYSTEM_PROCESSOR: x86_64
  -- x86 detected
  CMake Warning (dev) at CMakeLists.txt:18 (install):
    Target llama has PUBLIC_HEADER files but no PUBLIC_HEADER DESTINATION.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  CMake Warning (dev) at CMakeLists.txt:27 (install):
    Target llama has PUBLIC_HEADER files but no PUBLIC_HEADER DESTINATION.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  -- Configuring done (0.3s)
  -- Generating done (0.0s)
  -- Build files have been written to: /tmp/tmpzfkz647x/build
  *** Building project with Ninja...
  Change Dir: '/tmp/tmpzfkz647x/build'

  Run Build Command(s): /tmp/pip-build-env-ltem499n/normal/lib/python3.10/site-packages/ninja/data/bin/ninja -v
  [1/13] /usr/bin/c++ -DGGML_CUDA_DMMV_X=32 -DGGML_CUDA_MMV_Y=1 -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -DK_QUANTS_PER_ITERATION=2 -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -D__HIP_PLATFORM_AMD__=1 -D__HIP_PLATFORM_HCC__=1 -isystem /opt/rocm/include -isystem /opt/rocm-5.7.0/include -O3 -DNDEBUG -std=gnu++11 -fPIC -x hip -MD -MT vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o -MF vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o.d -o vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o -c /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/ggml-cuda.cu
  FAILED: vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o
  /usr/bin/c++ -DGGML_CUDA_DMMV_X=32 -DGGML_CUDA_MMV_Y=1 -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -DK_QUANTS_PER_ITERATION=2 -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -D__HIP_PLATFORM_AMD__=1 -D__HIP_PLATFORM_HCC__=1 -isystem /opt/rocm/include -isystem /opt/rocm-5.7.0/include -O3 -DNDEBUG -std=gnu++11 -fPIC -x hip -MD -MT vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o -MF vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o.d -o vendor/llama.cpp/CMakeFiles/ggml-rocm.dir/ggml-cuda.cu.o -c /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/ggml-cuda.cu
  c++: error: language hip not recognized
  c++: error: language hip not recognized
  [2/13] cd /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp && /tmp/pip-build-env-ltem499n/normal/lib/python3.10/site-packages/cmake/data/bin/cmake -DMSVC= -DCMAKE_C_COMPILER_VERSION=11.4.0 -DCMAKE_C_COMPILER_ID=GNU -DCMAKE_VS_PLATFORM_NAME= -DCMAKE_C_COMPILER=/usr/bin/cc -P /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/scripts/build-info.cmake
  -- Found Git: /usr/bin/git (found version "2.34.1")
  [3/13] /usr/bin/cc -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -D__HIP_PLATFORM_AMD__=1 -D__HIP_PLATFORM_HCC__=1 -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/. -isystem /opt/rocm/include -isystem /opt/rocm-5.7.0/include -O3 -DNDEBUG -std=gnu11 -fPIC -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -mf16c -mfma -mavx -mavx2 -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o -c /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/ggml-alloc.c
  [4/13] /usr/bin/c++ -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/common/. -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -fPIC -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wmissing-declarations -Wmissing-noreturn -Wno-array-bounds -Wno-format-truncation -Wextra-semi -mf16c -mfma -mavx -mavx2 -MD -MT vendor/llama.cpp/common/CMakeFiles/common.dir/console.cpp.o -MF vendor/llama.cpp/common/CMakeFiles/common.dir/console.cpp.o.d -o vendor/llama.cpp/common/CMakeFiles/common.dir/console.cpp.o -c /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/common/console.cpp
  [5/13] /usr/bin/c++ -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/common/. -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -fPIC -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wmissing-declarations -Wmissing-noreturn -Wno-array-bounds -Wno-format-truncation -Wextra-semi -mf16c -mfma -mavx -mavx2 -MD -MT vendor/llama.cpp/common/CMakeFiles/common.dir/grammar-parser.cpp.o -MF vendor/llama.cpp/common/CMakeFiles/common.dir/grammar-parser.cpp.o.d -o vendor/llama.cpp/common/CMakeFiles/common.dir/grammar-parser.cpp.o -c /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/common/grammar-parser.cpp
  [6/13] /usr/bin/cc -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -D__HIP_PLATFORM_AMD__=1 -D__HIP_PLATFORM_HCC__=1 -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/. -isystem /opt/rocm/include -isystem /opt/rocm-5.7.0/include -O3 -DNDEBUG -std=gnu11 -fPIC -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -mf16c -mfma -mavx -mavx2 -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/k_quants.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/k_quants.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/k_quants.c.o -c /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/k_quants.c
  [7/13] /usr/bin/c++ -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/common/. -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -fPIC -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wmissing-declarations -Wmissing-noreturn -Wno-array-bounds -Wno-format-truncation -Wextra-semi -mf16c -mfma -mavx -mavx2 -MD -MT vendor/llama.cpp/common/CMakeFiles/common.dir/train.cpp.o -MF vendor/llama.cpp/common/CMakeFiles/common.dir/train.cpp.o.d -o vendor/llama.cpp/common/CMakeFiles/common.dir/train.cpp.o -c /tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/common/train.cpp
  [8/13] /usr/bin/c++ -DGGML_USE_CUBLAS -DGGML_USE_HIPBLAS -DGGML_USE_K_QUANTS -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/common/. -I/tmp/pip-install-_x9a148g/llama-cpp-python_07818dae4b08428abdb523d8d3aa67c2/vendor/llama.cpp/.

  *** CMake build failed
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for llama-cpp-python
Failed to build llama-cpp-python
ERROR: Could not build wheels for llama-cpp-python, which is required to install pyproject.toml-based projects`

@DaniDD Try looking into iss #695. Similar reports there as well. They're definitely related.

I have a similar but slightly different problem. I'm running ROCM 6.0 on Ubuntu 22 and I instally pytorch with rocm 5.7. Now I updated the above install command for llama-cpp-python with the correct references for Rocm 6.0 and a 7900xt GPU (GFX 1100)
CMAKE_ARGS="-D LLAMA_HIPBLAS=ON -D CMAKE_C_COMPILER=/opt/rocm/bin/amdclang -D CMAKE_CXX_COMPILER=/opt/rocm/bin/amdclang++ -D CMAKE_PREFIX_PATH=/opt/rocm -D AMDGPU_TARGETS=gfx1100" FORCE_CMAKE=1 pip install llama-cpp-python==0.2.29 --upgrade --force-reinstall --no-cache-dir

This resulted in the following error
ERROR: Failed building wheel for llama-cpp-python

which is due to this suberror error: unable to find library -lstdc++
I fixed it by installing the latest g++ libraries with
sudo apt install libstdc++-12-dev
sudo apt install libstdc++-12-doc


AC3829 / 50 not responding - Error: spawnSync python3 ETIMEDOUT

I have a problem.
I connected an AC3829 / 50 air purifier to the system, which works perfectly (on / off, temperature, air purity, humidity) in both Homebridge and HomeKit.
It works like this for 1-2 hours. After that, however, the air purifier itself does not respond to anything, it don't send data from the HomeKit (no longer send data) and not response own CleanHome + application.
It only helps if I unplug the air purifier. Then it works again for a few hours but then it all starts all over again.
What could be the problem? Is the air purifier blocking communication? Has anyone else encountered this problem or the like?
Is there a solution?
Homebridge restart log:
Exception: sync timeout
[6/12/2021, 6:43:15 PM] [Philips Air] [Philips Air] Unable to load filter info: Error: Command failed: python3 /usr/local/lib/node_modules/homebridge-philips-air/node_modules/philips-air/pyaircontrol.py --ipaddr <IP_ADDRESS> --protocol coap --status
Give up on message From None, To ('<IP_ADDRESS>', 5683), CON-58070, POST-uf, [Uri-Path: sys, Uri-Path: dev, Uri-Path: sync, ] 61C55DAF...8 bytes
Traceback (most recent call last):
  File "/usr/local/lib/node_modules/homebridge-philips-air/node_modules/philips-air/pyaircontrol.py", line 123, in <module>
    main()
  File "/usr/local/lib/node_modules/homebridge-philips-air/node_modules/philips-air/pyaircontrol.py", line 99, in main
    c = CoAPCli(args.ipaddr)
  File "/usr/local/lib/node_modules/homebridge-philips-air/node_modules/philips-air/pyaircontrol.py", line 15, in __init__
    self._client = CoAPAirClient(host, port, False)
  File "/usr/lib/python3.8/site-packages/pyairctrl/coap_client.py", line 80, in __init__
    self._sync()
  File "/usr/lib/python3.8/site-packages/pyairctrl/coap_client.py", line 96, in _sync
    raise Exception("sync timeout")
Exception: sync timeout

[Philips Air] [Philips Air] Unable to get data for polling: Error: spawnSync python3 ETIMEDOUT.

https://github.com/NikDevx/homebridge-philips-air/issues/162
https://github.com/NikDevx/homebridge-philips-air/issues/167

https://github.com/NikDevx/homebridge-philips-air/issues/162
https://github.com/NikDevx/homebridge-philips-air/issues/167

Thx. Works fine.


core: reduce module ID size by not including full schemas

Before this, we were passing full introspection schema JSONs as strings as args to non-Go SDKs, which resulted in them being included in the full IDs for non-Go modules.
Those strings got huge and could appear multiple times in a single ID, which inflated their size, and also ended up in progress output (I think the source of ETOOBIG?) + telemetry.
This has been a known issue for a while but not harmful enough to be prioritized for a fix. However, my other PR that refactors a bunch of stuff around sessions ended up hitting this problem hard since it required including Module+FunctionCall IDs as HTTP headers, but then hitting limits on the max size of HTTP headers (go defaults to 1MB, which is pretty reasonable+generous).

Some headers in that PR that previously ended up summing to 1.7MB now max out at 70kb (still too high but I think there's other issues to fix separately).

The fix here changes the introspection json to be passed as type File rather than string. The File is created using the existing blob-functionality so it's all nice and content hashed.
As I updated the SDK implementations to account for this (technically a small breaking change), I also noticed that all of them turned the string into a File anyways internally, so this seems like an all around better approach for everyone involved.

cc @helderco @TomChv @wingyplus this is a very small but technically breaking change to the SDKs-as-modules interface, as noted above, so just FYI. Let me know if there's anyone else I should @

I think we need to add a note to Elixir SDK to pin the SDK version for any users who uses dagger released version because it can be broken if user uses the runtime on latest main branch.
I can help update a note after this PR merged. So you might not need to worry about it.

Nice 🎉 @wingyplus if you can add a breaking change note to this PR, I think that works 🎉
We should probably note this for the engine notes (not just elixir) since it is an engine interface change. Even though it's a breaking change, I think in practice this is fine to pull into the next v0.11.X release.

For Elixir, add a note to the sdk/elixir/README.md would be enough. But for the engine, we should add a changie log right?

Nice 🎉 @wingyplus if you can add a breaking change note to this PR, I think that works 🎉
We should probably note this for the engine notes (not just elixir) since it is an engine interface change. Even though it's a breaking change, I think in practice this is fine to pull into the next v0.11.X release.

For Elixir, add a note to the sdk/elixir/README.md would be enough. But for the engine, we should add a changie log right?

Yup, exactly that SGTM :pray:

@wingyplus good call on handling the elixir SDK breaking change more carefully! I added just a changie log for now; wasn't sure the format/way to include the breaking change note in sdk/elixir/README.md you'd prefer so will just leave that to you. Thank you!

Test failures are the ones fixed by https://github.com/dagger/dagger/pull/7452 so just gonna merge as is rather than keep re-rolling


Does not flag allowed terms when those terms are not starting with the non-inclusive term

The allowed term that did not start with the non-inclusive term was added as an offense.

Hey @mecastelom! Are you able to resolve the conflict introduced by this PR?

Hey @mecastelom! Are you able to resolve the conflict introduced by this PR?

Sure, I will work on that

Looking forward to this fix -- it will help us begin to use the inclusive-code linter in our projects at work.

Sorry for the delay on merging this! I'm working on bumping the version/releasing this code to the gem now.


Update custom

Updating the example in the Custom Claims provider in Microsoft Entra documentation. It wasn't a valid JSON document.

@cilwerner
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


HDFS-17523: Add fine-grained locks metrics in DataSetLockManager

Add fine-grained lock held info when the lock holding time reaches the specified threshold.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 48s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
50m  3s

trunk passed

+1 :green_heart:
compile
1m 27s

trunk passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
compile
1m 13s

trunk passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
checkstyle
1m 14s

trunk passed

+1 :green_heart:
mvnsite
1m 21s

trunk passed

+1 :green_heart:
javadoc
1m  9s

trunk passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
javadoc
1m 46s

trunk passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
spotbugs
3m 19s

trunk passed

+1 :green_heart:
shadedclient
41m  9s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
41m 30s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 13s

the patch passed

+1 :green_heart:
compile
1m 16s

the patch passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
javac
1m 16s

the patch passed

+1 :green_heart:
compile
1m  6s

the patch passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
javac
1m  6s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m  5s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 68 new + 358 unchanged - 0 fixed = 426 total (was 358)

+1 :green_heart:
mvnsite
1m 14s

the patch passed

+1 :green_heart:
javadoc
0m 55s

the patch passed with JDK Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2

+1 :green_heart:
javadoc
1m 35s

the patch passed with JDK Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

+1 :green_heart:
spotbugs
3m 24s

the patch passed

+1 :green_heart:
shadedclient
40m 57s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
264m 59s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

419m 53s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestRollingUpgrade

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6886/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6886

JIRA Issue
HDFS-17523

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets xmllint

uname
Linux 00339d4c6bf9 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d204721301f8ce93bcd8c3f8277a193e1ac72743

Default Java
Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.23+9-post-Ubuntu-1ubuntu120.04.2 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_412-8u412-ga-1~20.04.1-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6886/1/testReport/

Max. process+thread count
3025 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6886/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


Improve unit tests coverage in the jetstream reconciler v2

Description
As a follow-up to this PR, we want to cover the uncovered edge-cases with unit tests.
Reasons
We aim for 100% unit test coverage.

false project


Support relative path in tool location settings

Using the following to point VS Code at the Helm install doesn't appear to work:
        "vs-kubernetes": {
            "vs-kubernetes.helm-path.linux": "${workspaceFolder}/tools/bin/helm"
        }

Is this expected? I've noticed some extensions support this while others do not.

The Terraform extension appears to support it, at the workspace level.
I'll have to try without workspace, I was trying to configure it as part of the workspace (for a company wide workspace).

bump. This is a blocker to creating developer environments with tools and dependencies that are local to a workspace. For example, https://devenv.sh


docs: Link to HOWTO_android.md in other docs

Link to the new HOWTO_android.md doc from inside the BUILD.md and USAGE_android.md docs so that people can know of the existence of this new document.

CI gfxreconstruct build queued with queue ID 8079.

CI gfxreconstruct build # 2751 running.

CI gfxreconstruct build # 2751 passed.


KeyVault multi-version tests for certs / secrets / (possibly) admin

In #14587 we added multi-version test support for KV Keys.
This issue tracks adding the same support for:

[ ] KeyVault Certificates
[ ] KeyVault Secrets

I'm debating about KeyVault Admin. Currently there's only one version that supported, but on the other hand 7.3 will come soon enough.

Closing in favor of #13662 - did not realize an issue was already created


What about wayland?

Has anyone tried to get wayland working instead of X for the chromebooks?
Might be a potential fix to the issues people are having with the pixel with beta Chrome OS. If that happens to go live I dont think testing this to get it working will be as nice.

I'm looking into it using the cyan platform with chromiumos r52 (it's using freon). Basically, everything is different because there is no tty.
Here is my strategy:

use a systemd chroot (there is another pull request I improved that deals with entering the chroot using nsenter to emulate a full system using systemd)
use systemd-logind which can handle user sessions when there is no tty present
register a croutonfreon session to systemd-logind. It's a session that will grab the DRI device by default, and forward the dbus calls to pause and resume access to the device to the host cros dbus service
have a way to enter the chroot in a new session that is associated with seat0 in logind
make sure weston doesn't need a tty and use all the dbus calls to logind that are appropriate

So far, I could get rid of the LD_PRELOAD hack (bacause logind works well when there is no tty). The only patchs that will need to happen is for display managers (weston, xorg if we want to run it in the same mode) to make sure they do not access the devices directly (through /dev) but through logind, and to make sure they don't use a tty at all.
I'm learning many things here.

weston needs quite a bit of modifications.
First, it needs to continue even when there is no VT. This is a simple removal of goto err_session in function launcher_logind_connect.
Then, there is a timing problem. When weston starts, it tells logind it needs a DRM device. logind takes the device from the croutonfreonsession wrapper. it doesn't wait to get the feedback from the wrapper before giving it back to weston.
Unfortunately, freon doesn't release the DRM master instantly. logind assumes it can take the device away because it had given it away in the first place. Unfortunately, on chromiumos, freon is the first one here to get to the DRM device, and logind cannot take the device instantly.
logind then gives the device to weston, but without the DRM_MASTER because for a short time, freon still has it. This is a very weird scenario for weston because the device opens up successfully, but without DRM_MASTER as expected. Trying to draw on it will fail, and weston won't even imagine it can take the DRM_MASTER and it will work.
For the moment, I modified weston to detect when logind gives it a drm device that isn't master. In such cases, it will wait a little, release the device, and take it again from logind, hoping this time it will be master. if this fails, it aborts after 5 times.
I'm not sure this is the best way to do it. Ideally, freon should be able to run using the DRM device given by logind (a file descriptor given through dbus) instead of opening it from /dev. This way, logind can take the DRM_MASTER forcefully.
Or, we could tell logind that the freon session is special and cannot release the DRM device instantly. Logind should wait for the freon session before giving the DRM device to anyone else.

Google Chrome 50 Released With Wayland Support


When tile size does not match the texture provided, emit informative error message.

Currently, if your TilemapTileSize does not match the size of the tile in the texture, then you are liable to get errors like:
thread 'Compute Task Pool (0)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_texture
      note: label = `texture_array`
    Dimension Z is zero

Is there a way to emit an error message that is more informative?

At least for a vector of tiles, we now do this check and panic with an informative message: https://github.com/StarArawn/bevy_ecs_tilemap/blob/eabd66eac4c5204ec54646141ffb26935cace88d/src/render/extract.rs#L114
It remains a little unclear to me how this can be extended also to the atlas/TilemapTexture::Single variants.


Hide search pane

I've searched the ten first pages of issues with the term "search" but couldn't find this issue.
I can toggle search by pressing CTRL+F, as it should. However, I can't find any way to close that pane. Maybe an x would be nice or at least a notion of the search pane in View?
It doesn't seem like a good idea to be able to toggle it with CTRL+F. That one should only be used for opening the search box. That way you can't accidentally close the search box when it's already open.

Hope that helps!

Strange, I don't remember getting that notification. It does seem to me that this is a bad idea. The ESC seems like such a global key that it shouldn't be used for closing a pane inside the programme. But I now realise that that there's a find-and-replace package, so I'll file an issue/feature request there. Thanks for the pointer!


Please implement \overline

Hello!
Please implement \overline. This command doesn't work now.
Thanks.

Try to build my fork, it should work now.


Kotlin 1.7.0 breaking changes

Updating my sample project from Kotlin 1.6.21 to 1.7.0 breaks the plugin
Sample project:
https://github.com/jdvp/AndroidAspectExample
You can check out master and just update the Kt version. Prior to updating ./gradlew clean lint test will run successfully and after updating it will fail with the following error:
* What went wrong:
Could not determine the dependencies of task ':app:aopWeaveDebug'.
> class org.jetbrains.kotlin.gradle.tasks.KotlinCompile_Decorated cannot be cast to class org.gradle.api.tasks.compile.AbstractCompile (org.jetbrains.kotlin.gradle.tasks.KotlinCompile_Decorated is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @6f886d4a; org.gradle.api.tasks.compile.AbstractCompile is in unnamed module of loader org.gradle.initialization.MixInLegacyTypesClassLoader @6cc4cdb9)

This appears to be because of the following:

Kotlin compile tasks no longer inherit the Gradle AbstractCompile task. They inherit only the DefaultTask.

which is mentioned in the What's new in 1.7.0 Changes in compile tasks section

Published 1.4.0 which adds support for Kotlin 1.7.0.

@vdelricco Just checking, I noticed that 1.4.0 release notes mention that it requires Kt 1.7.0 but is that true? I tried compiling my app with Ibotta 1.4.0 and Kt 1.5.0 and it seemed to work?

Oh interesting! It's certainly possible there are some build configurations that work properly. When applying this to our main app codebase, I received the following error when using the 1.4.0 release of this plugin:
FAILURE: Build failed with an exception.

* What went wrong:
'org.gradle.api.file.ConfigurableFileCollection org.jetbrains.kotlin.gradle.tasks.KotlinCompile.getLibraries()'

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
java.lang.NoSuchMethodError: 'org.gradle.api.file.ConfigurableFileCollection org.jetbrains.kotlin.gradle.tasks.KotlinCompile.getLibraries()'
        at com.ibotta.gradle.aop.PipelineAopWeaverPlugin.gatherClasspaths(PipelineAopWeaverPlugin.kt:386)
        at com.ibotta.gradle.aop.PipelineAopWeaverPlugin.access$gatherClasspaths(PipelineAopWeaverPlugin.kt:34)
        at com.ibotta.gradle.aop.PipelineAopWeaverPlugin$configureAopWeaveTask$1$2.invoke(PipelineAopWeaverPlugin.kt:297)
        at com.ibotta.gradle.aop.PipelineAopWeaverPlugin$configureAopWeaveTask$1$2.invoke(PipelineAopWeaverPlugin.kt:34)
        at com.ibotta.gradle.aop.AopWeaveTask.getClassPath(AopWeaveTask.kt:43)

I was able to get past this by updating our kotlin version from 1.6.10 to 1.7.0 (and then faced other errors later on because we're not quite ready for 1.7.0 😅) which was the reason for the note in the 1.4.0 release. I didn't do much digging after that though, so like I said this may be limited to our build config and will work in some other scenarios. Would be interested to hear if you uncover anything else 😄


add if statment if alredy voted

Heard that you get error that it has already voted on a post, this or something similar to this should stop that as beem has a check if the account has already voted.

since I'm not to familiar with the code, i didn't read enough to see if voter was an Account object or just a string, if the later, instead of if voter.has_voted(c) is False: use if Account(voter).has_voted(c) is False:

glad i could at least help somewhere


Fix issue with Security Hub integration when resolving closed findings are either a lot of new findings, or a lot of resolved findings @Kirizan

Fixes #950
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks @Kirizan this is a great improvement!


Reading 1 assignment

Suggestions for the Reading 1 (W1_2)

I like chapter 2 of the geron book where he gives an overview of the steps you go through in a machine learning projects. A summary of this in the beginning of the part II of the E-Book would be nice as an introduction


Fix/repo path to new argoproj-labs/argocd-interlance

Signed-off-by: Yuji Watanabe<EMAIL_ADDRESS>

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


typo

PR-Codex overview
This PR adds proper grammar to the README.md file and creates objects for handling Queries, Commands, and Events in Event Sourcing & CQRS.
Detailed summary:

Added a comma after "Commands" for proper grammar.
Created objects for handling Queries, Commands, and Events in Event Sourcing & CQRS.
Added a motivation section explaining the need for these objects.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@h1alexbel OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@h1alexbel Done! FYI, the full log is here (took me 1min)


initial implementation of pvsyst_celltemp function (#552)

[x] Closes issue #552
[x] I am familiar with the contributing guidelines.
[x] Fully tested. Added and/or modified tests to ensure correct behavior for all reasonable inputs. Tests (usually) must pass on the TravisCI and Appveyor testing services.
[x] Updates entries to docs/sphinx/source/api.rst for API changes.
[x] Adds description and name entries in the appropriate docs/sphinx/source/whatsnew file for all changes.
[x] Code quality and style is sufficient. Passes LGTM and SticklerCI checks.
[x] New code is fully documented. Includes sphinx/numpydoc compliant docstrings and comments in the code where necessary.
[x] Pull request is nearly complete and ready for detailed review.

I think the temp_model keys you are using are fine.  They trace back to two defaults that PVsyst offers: see the Array Thermal losses page of the PVsyst v6 help files.
Be sure to update api.rst and whatsnew.rst.
Thanks for the contribution!

@CameronTStark could you Resolve conversation for the formatting items you've addressed?  Thanks.

@cwhanse @CameronTStark why the closing and reopening? can we leave it open until merged?

@cwhanse @CameronTStark why the closing and reopening? can we leave it open until merged?

Sorry, I hit the Comment and close button by accident.

I made a handful of minor comments below (hoping that this still works with the PR closed).

@wholmgren it looks like the PR isn't updating with my latest commit now that its closed again. Maybe it'll update if it's reopened?

I also must have mis-clicked and closed it.

@CameronTStark can you try to resolve the merge conflict? Then I think it's ready to merge.

Thanks for the contribution @CameronTStark

Thanks for the contribution @CameronTStark

Sure thing and thanks for the easy introduction to contributing here.
If there's another place to contribute next that makes sense from here please let me know. If not I'll just check issues again and dive in.

Good comment, @Mikofski<EMAIL_ADDRESS>I hadn’t considered that.
Easy issue and PR, both welcome.
From: Mark Mikofski<EMAIL_ADDRESS>Sent: Tuesday, December 11, 2018 2:39 PM
To: pvlib/pvlib-python<EMAIL_ADDRESS>Cc: Hansen, Clifford W<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Subject: [EXTERNAL] Re: [pvlib/pvlib-python] initial implementation of pvsyst_celltemp function (#552) (#628)
@mikofski commented on this pull request.

In pvlib/pvsystem.pyhttps://github.com/pvlib/pvlib-python/pull/628#discussion_r240800654:

Returns

temp_cell : numeric or Series

   Cell temperature in degrees Celsius

References

[1]"PVsyst 6 Help", Files.pvsyst.com, 2018. [Online]. Available:

http://files.pvsyst.com/help/index.html. [Accessed: 10- Dec- 2018].

[2] Faiman, D. (2008). "Assessing the outdoor operating temperature of

photovoltaic modules." Progress in Photovoltaics 16(4): 307-315.

"""

temp_models = {"freestanding": (29.0, 0), "insulated": (15.0, 0)}

My thoughts in case this is ever revisited, sorry for commenting so late.

Move this constant to the module level. IMO avoid internally scoped constants. The computer needs to find memory for this every time this function is called. If it's defined at the module level then I think this memory will only be allocated once, when the module is imported the first time.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/pvlib/pvlib-python/pull/628#pullrequestreview-183915995, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFJNLzUEc_NbGcuSybs0wDy2UPmKpN6xks5u4CXhgaJpZM4ZHfAi.

@CameronTStark thanks for this good pull request. A related contribution would be to add PVSystem and ModelChain wrappers for this new function. I suggest making a new issue for that feature if you want to pursue it.

#633

@CameronTStark thanks for this good pull request. A related contribution would be to add PVSystem and ModelChain wrappers for this new function. I suggest making a new issue for that feature if you want to pursue it.

Sounds good. I'll get on it. Thanks!

@CameronTStark thanks!  Just a note, the method tests should verify that the object methods call the underlying function, there's not a need to retest the function's output.


Update quidel docstrings to pass pydocstyle

Summary of changes:

Update docstrings so they pass the pydocstyle linter, which checks against most of PEP257
geomapping and data tools (smoothing) functions are excluded until refactors go through

going to close this until we figure out branching


Local Invoker

Is the idea of creating a functional interface with the necessary signature to call the constructor.newInstance(args) or method.invoke(args) within it. While all implementations would do so they are all defined in a different "local" place hence having access to other package local classes and methods.
This is essentially an idea to allow package and default visibility to be used without using deep reflection. The price is that each package needs to define the local invoker method and bind it as method reference to the defined functional interface.
The suppliers using reflection then resolve it local to their package and if it was defined they can access the package and default visible classes and methods as the method actually executing the reflection is local.

Implemented by #173

Implemented by #173


Cannot use TrackTotalHits when making ES query

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.
Which version of Elastic are you using?
[ ] elastic.v6 (for Elasticsearch 6.x)
Please describe the expected behavior
I am trying to make track_total_hits: false in search_service. But it seems that it is not available in Search_service.
Please describe the actual behavior
It is available in SearchSource which we can use in SearchService but I am not sure is it a bug or there is another way to use it.
Any steps to reproduce the behavior?

Create elasticsearch client for Search() method. There I cannot use TrackTotalHits but can use TrackScores

@olivere Can you please take a look as it is mentioned in this code documentation that default is true. See here

If it isn't explicitly set by you, it takes the server's default value. That documentation is provided by the REST API specification from the good people at ES. So if you don't specify TrackTotalHits explicity, elastic won't serialize it and the server will pick its default value. The client shouldn't specify the default.

Fixed in next release of v6.


adding finally type (without implementation) at the pipeline level

Changes
Updating pipeline type to support finally. These changes are adding a new type and validation, does not implement this new functionality.
Design doc: https://docs.google.com/document/d/1lxpYQHppiWOxsn4arqbwAFDo4T0-LCqpNa6p-TJdHrw/edit#
Part of #1684
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[x] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Introducing a new clause under `pipeline` named `finally` where users can specify a list of tasks that will always execute, even if pipeline tasks fail. Adding a new type and its validation here, stay tuned for this functionality. Without implementing the functionality, a list of tasks under `finally` are validated but not executed at all.

/kind feature

Thanks for submitting this incremental PR!! This really makes it a lot easier to review thoroughly and really focus on this instead of trying to review everything at once

👍 ❤

Could you fill in the release notes? We want to be ready to release at any time, which means that for a change like this, we could potentially release the types before the functionality, which IMO is totally worth it, but in that case it's especially important that the release notes explain what is being added and the implications

Done, updated release notes

Related to the last request: can this PR also include an incremental update to the docs, e.g. adding the new field to the docs and explaining that currently this does nothing?

Shall I bring the entire section from the implementation PR here in pipelines.md?
@bobcatfish thanks a bunch for through review, I appreciate you taking time review this PR 🙏

Added summary of finally section in pipelines.md

I have dropped WIP label, this PR is ready to review, please let me know if any changes are required, its very exciting 🙏

/test pull-tekton-pipeline-integration-tests

/hold
Putting this hold just to make sure we wait for 0.13 before getting this merged :angel:

/hold cancel


Look at connect/connection language; investigate how hard it would be to only refer to data_import connections

For example, the StudyGrant flow currently refers to "connecting" and "connections" but really it's just authorizing grants; better to use that terminology because it's more specific and doesn't have crossover with data_import.
There's also confusion around the term "deeply integrated studies".

Maybe try to clarify "data import" vs "grant" whenever possible.


cannot find struct, variant or union type Invoke in module tauri::ipc

First of all thank you for the library, I think it'll be really useful once i get it working!
I followed along to your quick start guide so I used the same dependency versions as you
// /src-tauri/src/api/api.rs → gets imported to main.rs
use taurpc::{ procedures, resolvers };
use crate::system::focus::Focus::{ Focus, FocusModeList };

#[derive(Clone)]
pub struct ApiImpl;

#[taurpc::procedures]
trait Api {
    async fn get_all_focus_modes();
}

#[taurpc::resolvers]
impl Api for ApiImpl {
    async fn get_all_focus_modes(self) -> FocusModeList {
        let focus_list = Focus::new().get_all_focus_modes(true);
        return focus_list;
    }
}

i get the following errors for the macro use:

I can see all the mentioned members defined (Invoke & TauRpcHandler) so I have no idea where this is coming from...
Am I missing something here or is it just a bug?
OS: MacOS Sonoma 14.4
Rustc: rustc 1.70.0 (90c541806 2023-05-31)
Tauri: version 1

Hi, I think this has something to do with the tauri v2 alpha version. If you are using tauri v1 you should install taurpc version 0.2.3.
If you want to use tauri v2 alpha, you can look at the branch in this repository I created for it.
I will look into this later and support newer beta versions of tauri. Hopefully this helps you.

Thanks for reporting this issue. The taurpc crate was using a newer dependency that was meant for tauri v2 support.
You should be able to resolve your issue now by changing the taurpc version.
taurpc = "0.2.4"


add buildType profile=gc

allows to dub build -b profile=gc to trace memory allocations

The only thing I wonder if we should maybe name it "profile-gc" instead of using a an equals sign, which might produce a syntax conflict in certain situations (although it doesn't currently, AFAICS). The enum member name should be profileGC to comply with the general naming rules.

done

Thanks!


Update copyright header definitions and add missing IDs

Addresses the following issues:
The copyright header examples in the Microsoft OSS docs are out of date (heard from an email forwarded from Larry, not sure if this is officially posted anywhere) and should actually be the following:
Copyright (c) Microsoft Corporation.
Licensed under the MIT license.

Additionally, many guidelines are missing guideline IDs, which allow linking to specific rules and provide naming conventions for rules used in @azure/eslint-plugin-azure-sdk.
The ID names I've added here are only my ideas and any improvements/changes are welcome.

We are currently moving the guidelines to a Jekyll formatted site.  I'll take a look at these with an eye to updating the Jekyll site, not the current guidelines (unless there is urgency that requires this be done in the next ~2 weeks)

I think the only pressing thing would be the update to the copyright header definitions.

Got it - the current spec links to the official guidance.  We should be working on getting the official Microsoft OSS guidance updated - not telling people to do something different.  Double-checking the linked document, it says the same thing, so I don't see the issue.  Perhaps you can clarify why the linked document is wrong?

@adrianhall apparently official guidance is out of date. @arpanlaha's text does differ, e.g. "All rights reserved." should no longer be present in the copyright header.

Point still remains.  If we "copy the guidance", it will inevitably become out of date.  We should be pointing to the official guidance.  If the official guidance is wrong, let's get the official guidance updated to match the appropriate language.

Incorporated this guidance into docs/policies/opensource.md of PR #537 (which reformats the entire site).  Closing this one as a result of that change.


[ci skip] adding user @sisodia1701

Hi! This is the friendly automated conda-forge-webservice.
I've added user @sisodia1701 as instructed in #40.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Please contact conda-forge/core to have this PR merged, if the maintainer is unresponsive.
Fixes #40

@conda-forge-admin , please re-render


Finalized Filters and Paginator

Restructured the framework for how filters work and implemented a basic paginator. Commented out code that may be redundant now with the catalog filters working.

Moved to branch pr/61


Intermittent error in LoadBalancerTest.java

Expected behavior
mvn test completes successfully in 10-15 minutes.
Actual behavior
Tests run: 526, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 881.775 sec <<< FAILURE! - in TestSuite
testLoadReportsWrittenOnZK(com.yahoo.pulsar.broker.loadbalance.LoadBalancerTest)  Time elapsed: 0.027 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
	at com.yahoo.pulsar.broker.loadbalance.LoadBalancerTest.testLoadReportsWrittenOnZK(LoadBalancerTest.java:202)

testResumptionAfterBacklogRelaxed(com.yahoo.pulsar.broker.service.ReplicatorTest)  Time elapsed: 49.376 sec  <<< FAILURE!
com.yahoo.pulsar.client.api.PulsarClientException$TimeoutException: Could not send message to broker within given timeout

Results :

Failed tests:
  LoadBalancerTest.testLoadReportsWrittenOnZK:202 expected [true] but found [false]
  ReplicatorTest.testResumptionAfterBacklogRelaxed » Timeout Could not send mess...

Steps to reproduce
Intermittent test failure.
System configuration
Pulsar version: 17630b9c0386143714a12361d01713f695b4a73c

Tests run: 540, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 863.584 sec <<< FAILURE! - in TestSuite
testLoadReportsWrittenOnZK(com.yahoo.pulsar.broker.loadbalance.LoadBalancerTest)  Time elapsed: 0.012 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at com.yahoo.pulsar.broker.loadbalance.LoadBalancerTest.testLoadReportsWrittenOnZK(LoadBalancerTest.java:202)

Pulsar version: f0fbb4da55d60099af12159f7b7932f9ec4843b3

I think this flaky test is Has been fixed.
@lhotari


Question about future updates

Hey there, will there ever be a way to change the NPC Entity type?
E.g: making the NPC a Zombie, Skeleton, etc
Thanks,
Rainnny

Duplicate of #44.


[L5] Metrics and New Months

Ever since May 1st rolled around my metrics graphs have quit working - well kind of. My points are all (time, 0). I know my service is still posting them to the api, and you can see all of the points here: http://status.myweather.today/api/v1/metrics/1/points. I'm using the sum way to calculate the points.

Can you export the table for me and I'll take a look whilst on my dinner.

(So now) :)

Both metrics and metric_points tables :)

How do you want them exported? CSV, SQL, etc?

CSV is perfect :)

Alright, https://onedrive.live.com/?cid=0dd498fb8335650e&id=DD498FB8335650E%215975 Download the files with the _5-2, they are the ones you want!

Are you on MySQL or PgSQL?

MySQL

Thanks!

#thatwasquick ;) Thanks!


Cleaned up main DIR and added run script for new async ops

I created a dir called "experimental_run_scripts" to clean up the main directory.

Created a new run script form the notebook/Data_Preperation_streamlined.ipynb -> src/Data_Preperation_streamlined.py.

After trying out (and removing) a python script form of the data preparation streamline notebook, this PR has now returned to the default expectation: Moving old python files into a subdir


pick #1250 to tidb-7.5

pick #1250 to tidb-7.5, also include #1277 & #1284.

@cfzjywxk @MyonKeminta @crazycs520 PTAL


Switch to calico over weave

the cluster is initialized with Weave's CNI but to really do anything on Packet you need Calico for BGP + MetalLB

Don't object per se to using Calico over Weave - or even having it be configurable - but what do you mean by "to really do anything on Packet"?

Apologies, probably not the best wording. Because Packet doesn't have a "managed load balancer service" like other public clouds, you'd typically run MetalLB to get ingress into the cluster running on Packet. To run MetalLB you need the BGP configuration, which Weave doesn't offer. There are obviously alternatives like using NodePort, etc., but if the cluster was strapped with Calico (and had the kubeadm pod-network-cidr set to Packet's IP space) it would be more user friendly :)

Ah that. We have an open issue (and an almost-ready PR) to deploy metallb optionally as part of the ccm deployment. Not everyone wants it deployed automatically, but some do. It is blocked on a packet API issue for IP management, which is in the process of being resolved (I don't own it, so I don't have an ETA :-) ).
Once that one is in, we can work with weave+metallb, or calico+metallb. More than happy to get a calico option running here as well.

Is the IP management issue the BGP enablement you have to manually request? That's what I'm waiting for to get some ingress resources setup right now.
+1 for configurable options to specify the CNI. I'm opinionated on Calico for other reasons as well (e.g. like IPIP encap, policy management, Istio integration, etc.) so it's great to have it as a configurable option.

configurable options to specify the CNI

I am thinking to put it in the cluster.yaml. Currently it looks like:
apiVersion: "cluster.k8s.io/v1alpha1"
kind: Cluster
metadata:
  name: test1-dxi4a
spec:
    clusterNetwork:
        services:
            cidrBlocks: ["<IP_ADDRESS>/16"]
        pods:
            cidrBlocks: ["<IP_ADDRESS>/16"]
        serviceDomain: "cluster.local"
    providerSpec:
      value:
        apiVersion: "packetprovider/v1alpha1"
        kind: "PacketClusterProviderSpec"
        projectID: "585f011b-1b0a-4696-b466-5e42ecce0a33"
        caKeyPair:
          cert: ""
          key: ""

just adding it to providerSpec, since clusterNetwork doesn't have any room for it, so something like:
apiVersion: "cluster.k8s.io/v1alpha1"
kind: Cluster
metadata:
  name: test1-dxi4a
spec:
    clusterNetwork:
        services:
            cidrBlocks: ["<IP_ADDRESS>/16"]
        pods:
            cidrBlocks: ["<IP_ADDRESS>/16"]
        serviceDomain: "cluster.local"
    providerSpec:
      value:
        apiVersion: "packetprovider/v1alpha1"
        cni: "calico"  # or "weave" or whatever is supported
        kind: "PacketClusterProviderSpec"
        projectID: "585f011b-1b0a-4696-b466-5e42ecce0a33"
        caKeyPair:
          cert: ""
          key: ""

I'm opinionated on Calico

I can cut both ways. I do like weave's simplicity, and have been using it for longer. But I met the original Calico engineers back in their metaswitch days, did performance testing on it for linuxcon in Berlin and Tokyo a few years back (when we could travel safely...) and loved it, and did a lot of the multi-arch work on it. So, yeah, it has a special place in my heart. :-)
Going to get that in asap.

Nice! One other suggestion as you're adding that functionality (that I'm certain you may already be aware of): it would be great if you modified the default Calico manifest during the apply to match the pod CIDR passed in the cluster spec. If the pod CIDR in the cluster spec is leveraging <IP_ADDRESS>/12, the CNI is initialized using the same. Reference: https://github.com/packet-labs/kubernetes-bgp#calico
It's possible to change it after the fact, obviously, but it can be cumbersome if kubeadm (and subsequently kube-proxy) are created with one pod CIDR block and the CNI uses the default 192.xxx

Definitively. One of the nice things about Weave is how it has that cloud service that lets you generate the manifest with the right changes. Calico doesn't have it, but we can make it happen.


[Keyboard, iOS] Generate iOS's special key mapping

This PR accompanies https://github.com/flutter/engine/pull/34413 by generating a table of "special key mapping" for iOS.
This table has also been used by RawKeyboardIos in the framework, but has been hard-coded. With this PR, this hard-coded table is also generated by the script.
This PR should not need tests, since it only contains changes to auto-generation scrip and a refactor.
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

test-exempt: code refactor with no semantic change

@dkwingsmt Google testing seems stuck?


Too long URLs causing troubles with the combo box component in annotation detail

Testing Odalic agains ADEQUATe KB. Too long URIs causes to run out of the dialog, which is not nice.

Quick Solution: I would suggest to make the dialog a bit wider for now, so that we do not have such issues. Later on, this should be mitigated by using prefixes. But better solution is preferred, see below.
Better Solution: It should behave in the responsive way - so if the user changes resolution (see below), it should be able to cope with that - e.g. the component should be able to automatically adjust the size of the displayed portion of the URI or split the URI into more lines. For sure it is not the best idea to just display everything on one line without of the respect to the size of the dialog.

This was a little bit tricky, since UI-SelectBox component does not provide any method to deal with this (AFAIK). Hopefully solved, though.