uv add fails for torch on intel macs but uv pip works

Hi Team,
Setup:
I have the following setup
uv 0.5.11 (c4d0caaee 2024-12-19)

=== CPU INFO ===
Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz

=== OS INFO ===
ProductName:		macOS
ProductVersion:		15.1.1
BuildVersion:		24B91

Question
uv init
uv venv --python 3.12
source .venv/bin/activate
uv add torch

fails with

DEBUG uv 0.5.11 (c4d0caaee 2024-12-19)
DEBUG Found project root: /Users/arunpatro/projects/demo-torch
DEBUG No workspace root found, using project root
DEBUG Reading Python requests from version file at /Users/arunpatro/projects/demo-torch/.python-version
DEBUG Using Python request 3.12 from version file at .python-version
DEBUG The virtual environment's Python version satisfies 3.12
DEBUG Using request timeout of 30s
DEBUG Using request timeout of 30s
DEBUG Found static pyproject.toml for: demo-torch @ file:///Users/arunpatro/projects/demo-torch
DEBUG No workspace root found, using project root
DEBUG Solving with installed Python version: 3.12.5
DEBUG Solving with target Python version: >=3.12
DEBUG Adding direct dependency: demo-torch*
DEBUG Searching for a compatible version of demo-torch @ file:///Users/arunpatro/projects/demo-torch ()
DEBUG Adding transitive dependency for demo-torch==0.1.0: torch
DEBUG Found stale response for: https://pypi.org/simple/torch/
DEBUG Sending revalidation request for: https://pypi.org/simple/torch/
DEBUG Found not-modified response for: https://pypi.org/simple/torch/
DEBUG Searching for a compatible version of torch ()
DEBUG Selecting: torch==2.5.1 [compatible] (torch-2.5.1-cp312-cp312-manylinux1_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/8b/5c/36c114d120bfe10f9323ed35061bc5878cc74f3f594003854b0ea298942f/torch-2.5.1-cp312-cp312-manylinux1_x86_64.whl.metadata
DEBUG Adding transitive dependency for torch==2.5.1: filelock
DEBUG Adding transitive dependency for torch==2.5.1: fsspec*
DEBUG Adding transitive dependency for torch==2.5.1: jinja2*
DEBUG Adding transitive dependency for torch==2.5.1: networkx*
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=2.21.5, <2.21.5+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: setuptools{python_full_version >= '3.12'}*
DEBUG Adding transitive dependency for torch==2.5.1: sympy{python_full_version >= '3.9'}>=1.13.1, <1.13.1+
DEBUG Adding transitive dependency for torch==2.5.1: triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'}>=3.1.0, <3.1.0+
DEBUG Adding transitive dependency for torch==2.5.1: typing-extensions>=4.8.0
DEBUG Found stale response for: https://pypi.org/simple/jinja2/
DEBUG Sending revalidation request for: https://pypi.org/simple/jinja2/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cuda-cupti-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cuda-cupti-cu12/
DEBUG Found stale response for: https://pypi.org/simple/filelock/
DEBUG Sending revalidation request for: https://pypi.org/simple/filelock/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cublas-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cublas-cu12/
DEBUG Found stale response for: https://pypi.org/simple/networkx/
DEBUG Sending revalidation request for: https://pypi.org/simple/networkx/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cuda-runtime-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cuda-runtime-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cusolver-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cusolver-cu12/
DEBUG Found stale response for: https://pypi.org/simple/fsspec/
DEBUG Sending revalidation request for: https://pypi.org/simple/fsspec/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cuda-nvrtc-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cuda-nvrtc-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-nccl-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-nccl-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-nvjitlink-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-nvjitlink-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cudnn-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cudnn-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cufft-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cufft-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-curand-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-curand-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-nvtx-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-nvtx-cu12/
DEBUG Found stale response for: https://pypi.org/simple/nvidia-cusparse-cu12/
DEBUG Sending revalidation request for: https://pypi.org/simple/nvidia-cusparse-cu12/
DEBUG Found stale response for: https://pypi.org/simple/triton/
DEBUG Sending revalidation request for: https://pypi.org/simple/triton/
DEBUG Found stale response for: https://pypi.org/simple/typing-extensions/
DEBUG Sending revalidation request for: https://pypi.org/simple/typing-extensions/
DEBUG Found stale response for: https://pypi.org/simple/sympy/
DEBUG Sending revalidation request for: https://pypi.org/simple/sympy/
DEBUG Found stale response for: https://pypi.org/simple/setuptools/
DEBUG Sending revalidation request for: https://pypi.org/simple/setuptools/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cusparse-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/networkx/
DEBUG Found not-modified response for: https://pypi.org/simple/fsspec/
DEBUG Found not-modified response for: https://pypi.org/simple/jinja2/
DEBUG Found not-modified response for: https://pypi.org/simple/typing-extensions/
DEBUG Found not-modified response for: https://pypi.org/simple/sympy/
DEBUG Found not-modified response for: https://pypi.org/simple/triton/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-curand-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cuda-runtime-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cusolver-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-nvtx-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/filelock/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-nccl-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cublas-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-nvjitlink-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cufft-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cudnn-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cuda-cupti-cu12/
DEBUG Found not-modified response for: https://pypi.org/simple/setuptools/
DEBUG Found not-modified response for: https://pypi.org/simple/nvidia-cuda-nvrtc-cu12/
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/de/86/5486b0188d08aa643e127774a99bac51ffa6cf343e3deb0583956dca5b22/fsspec-2024.12.0-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/b9/54/dd730b32ea14ea797530a4479b2ed46a6fb250f682a9cfb997e968bf0261/networkx-3.4.2-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/bd/0f/2ba5fbcd631e3e88689309dbe978c5769e883e4b84ebfe7da30b43275c5a/jinja2-3.1.5-py3-none-any.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/26/9f/ad63fc0248c5379346306f8668cda6e2e2e9c95e01216d2b8ffd9ff037d0/typing_extensions-4.12.2-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of filelock ()
DEBUG Selecting: filelock==3.16.1 [compatible] (filelock-3.16.1-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/b9/f8/feced7779d755758a52d1f6635d990b8d98dc0a29fa568bbe0625f18fdf3/filelock-3.16.1-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of fsspec ()
DEBUG Selecting: fsspec==2024.12.0 [compatible] (fsspec-2024.12.0-py3-none-any.whl)
DEBUG Searching for a compatible version of jinja2 ()
DEBUG Selecting: jinja2==3.1.5 [compatible] (jinja2-3.1.5-py3-none-any.whl)
DEBUG Adding transitive dependency for jinja2==3.1.5: markupsafe>=2.0
DEBUG Searching for a compatible version of networkx ()
DEBUG Selecting: networkx==3.4.2 [compatible] (networkx-3.4.2-py3-none-any.whl)
DEBUG Searching for a compatible version of nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [compatible] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cublas-cu12==<IP_ADDRESS>: nvidia-cublas-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cublas-cu12==<IP_ADDRESS>: nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [compatible] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/7f/7f/7fbae15a3982dc9595e49ce0f19332423b260045d0a6afe93cdbe2f1f624/nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cublas-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [compatible] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [compatible] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-cupti-cu12==12.4.127: nvidia-cuda-cupti-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-cupti-cu12==12.4.127: nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [compatible] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/93/b5/9fb3d00386d3361b03874246190dfec7b206fd74e6e287b26a8fcb359d95/nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [compatible] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [compatible] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-nvrtc-cu12==12.4.127: nvidia-cuda-nvrtc-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-nvrtc-cu12==12.4.127: nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [compatible] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/77/aa/083b01c427e963ad0b314040565ea396f914349914c298556484f799e61b/nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [compatible] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [compatible] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-runtime-cu12==12.4.127: nvidia-cuda-runtime-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-runtime-cu12==12.4.127: nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Found stale response for: https://pypi.org/simple/markupsafe/
DEBUG Sending revalidation request for: https://pypi.org/simple/markupsafe/
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [compatible] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/a1/aa/b656d755f474e2084971e9a297def515938d56b466ab39624012070cb773/nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [compatible] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [compatible] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cudnn-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [compatible] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/9f/fd/713452cd72343f682b1c7b9321e23829f00b842ceaedcda96e742ea0b0b3/nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Searching for a compatible version of nvidia-cudnn-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [compatible] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Searching for a compatible version of nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [compatible] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-cufft-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [compatible] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/7a/8a/0e728f749baca3fbeffad762738276e5df60851958be7783af121a7221e7/nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cufft-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [compatible] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [compatible] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-curand-cu12==<IP_ADDRESS>: nvidia-curand-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-curand-cu12==<IP_ADDRESS>: nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [compatible] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/9d/d7/c5383e47c7e9bf1c99d5bd2a8c935af2b6d705ad831a7ec5c97db4d82f4f/nvidia_nvjitlink_cu12-12.6.85-py3-none-manylinux2010_x86_64.manylinux_2_12_x86_64.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/80/9c/a79180e4d70995fdf030c6946991d0171555c6edf95c265c6b2bf7011112/nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-curand-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [compatible] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [compatible] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusolver-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [compatible] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/46/6b/a5c33cf16af09166845345275c34ad2190944bcc6026797a39f8e0a282e0/nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusolver-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [compatible] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [compatible] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cusparse-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [compatible] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/eb/eb/6681efd0aa7df96b4f8067b3ce7246833dd36830bb4cec8896182773db7d/nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.manylinux_2_17_aarch64.whl.metadata
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/96/a9/c0d2f83a53d40a4a41be14cea6a0bf9e668ffcf8b004bd65633f433050c0/nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [compatible] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=2.21.5, <2.21.5+)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [compatible] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-nccl-cu12==2.21.5: nvidia-nccl-cu12==2.21.5
DEBUG Adding transitive dependency for nvidia-nccl-cu12==2.21.5: nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==2.21.5
DEBUG Searching for a compatible version of nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==2.21.5)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [compatible] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/df/99/12cd266d6233f47d00daf3a72739872bdc10267d0383508b0b9c84a18bb6/nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl.metadata
DEBUG Searching for a compatible version of nvidia-nccl-cu12 (==2.21.5)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [compatible] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [compatible] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-nvjitlink-cu12==12.4.127: nvidia-nvjitlink-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-nvjitlink-cu12==12.4.127: nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12 (==12.4.127)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [compatible] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/02/45/239d52c05074898a80a900f49b1615d81c07fceadd5ad6c4f86a987c0bc4/nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [compatible] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [compatible] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-nvtx-cu12==12.4.127: nvidia-nvtx-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-nvtx-cu12==12.4.127: nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [compatible] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/06/39/471f581edbb7804b39e8063d92fc8305bdc7a80ae5c07dbe6ea5c50d14a5/nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl.metadata
DEBUG Searching for a compatible version of nvidia-nvtx-cu12 (==12.4.127)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [compatible] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} ()
DEBUG Selecting: setuptools==75.6.0 [compatible] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools==75.6.0
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools{python_full_version >= '3.12'}==75.6.0
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [compatible] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/55/21/47d163f615df1d30c094f6c8bbb353619274edccf0327b185cc2493c2c33/setuptools-75.6.0-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of setuptools (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [compatible] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (>=1.13.1, <1.13.1+)
DEBUG Selecting: sympy==1.13.1 [compatible] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: sympy==1.13.1
DEBUG Adding transitive dependency for sympy==1.13.1: sympy{python_full_version >= '3.9'}==1.13.1
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [compatible] (sympy-1.13.1-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/b2/fe/81695a1aa331a842b582453b605175f419fe8540355886031328089d840a/sympy-1.13.1-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of sympy (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [compatible] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'} (>=3.1.0, <3.1.0+)
DEBUG Selecting: triton==3.1.0 [compatible] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for triton==3.1.0: triton==3.1.0
DEBUG Adding transitive dependency for triton==3.1.0: triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'}==3.1.0
DEBUG Searching for a compatible version of triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'} (==3.1.0)
DEBUG Selecting: triton==3.1.0 [compatible] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/78/eb/65f5ba83c2a123f6498a3097746607e5b2f16add29e36765305e4ac7fdd8/triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
DEBUG Adding transitive dependency for triton==3.1.0: filelock
DEBUG Searching for a compatible version of triton (==3.1.0)
DEBUG Selecting: triton==3.1.0 [compatible] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for triton==3.1.0: filelock*
DEBUG Searching for a compatible version of typing-extensions (>=4.8.0)
DEBUG Selecting: typing-extensions==4.12.2 [compatible] (typing_extensions-4.12.2-py3-none-any.whl)
DEBUG Found stale response for: https://pypi.org/simple/mpmath/
DEBUG Sending revalidation request for: https://pypi.org/simple/mpmath/
DEBUG Found not-modified response for: https://pypi.org/simple/markupsafe/
DEBUG Searching for a compatible version of markupsafe (>=2.0)
DEBUG Selecting: markupsafe==3.0.2 [compatible] (MarkupSafe-3.0.2-cp312-cp312-macosx_10_13_universal2.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/22/09/d1f21434c97fc42f09d290cbb6350d44eb12f09cc62c9476effdb33a18aa/MarkupSafe-3.0.2-cp312-cp312-macosx_10_13_universal2.whl.metadata
DEBUG Found not-modified response for: https://pypi.org/simple/mpmath/
DEBUG Searching for a compatible version of mpmath (>=1.1.0, <1.4)
DEBUG Selecting: mpmath==1.3.0 [compatible] (mpmath-1.3.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/43/e3/7d92a15f894aa0c9c4b49b8ee9ac9850d6e63b03c9c32c0367a13ae62209/mpmath-1.3.0-py3-none-any.whl.metadata
DEBUG Tried 24 versions: demo-torch 1, filelock 1, fsspec 1, jinja2 1, markupsafe 1, mpmath 1, networkx 1, nvidia-cublas-cu12 1, nvidia-cuda-cupti-cu12 1, nvidia-cuda-nvrtc-cu12 1, nvidia-cuda-runtime-cu12 1, nvidia-cudnn-cu12 1, nvidia-cufft-cu12 1, nvidia-curand-cu12 1, nvidia-cusolver-cu12 1, nvidia-cusparse-cu12 1, nvidia-nccl-cu12 1, nvidia-nvjitlink-cu12 1, nvidia-nvtx-cu12 1, setuptools 1, sympy 1, torch 1, triton 1, typing-extensions 1
DEBUG all marker environments resolution took 0.193s
Resolved 24 packages in 221ms
DEBUG Using request timeout of 30s
DEBUG Found static pyproject.toml for: demo-torch @ file:///Users/arunpatro/projects/demo-torch
DEBUG No workspace root found, using project root
DEBUG Ignoring existing lockfile due to mismatched requires-dist for: demo-torch==0.1.0
Expected: {Requirement { name: PackageName("torch"), extras: [], groups: [], marker: true, source: Registry { specifier: VersionSpecifiers([VersionSpecifier { operator: GreaterThanEqual, version: "2.5.1" }]), index: None, conflict: None }, origin: None }}
Actual: {Requirement { name: PackageName("torch"), extras: [], groups: [], marker: true, source: Registry { specifier: VersionSpecifiers([]), index: None, conflict: None }, origin: None }}
DEBUG Solving with installed Python version: 3.12.5
DEBUG Solving with target Python version: >=3.12
DEBUG Adding direct dependency: demo-torch*
DEBUG Searching for a compatible version of demo-torch @ file:///Users/arunpatro/projects/demo-torch ()
DEBUG Adding transitive dependency for demo-torch==0.1.0: torch>=2.5.1
DEBUG Searching for a compatible version of torch (>=2.5.1)
DEBUG Selecting: torch==2.5.1 [preference] (torch-2.5.1-cp312-cp312-manylinux1_x86_64.whl)
DEBUG Adding transitive dependency for torch==2.5.1: filelock
DEBUG Adding transitive dependency for torch==2.5.1: fsspec*
DEBUG Adding transitive dependency for torch==2.5.1: jinja2*
DEBUG Adding transitive dependency for torch==2.5.1: networkx*
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=<IP_ADDRESS>, <<IP_ADDRESS>+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=2.21.5, <2.21.5+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}>=12.4.127, <12.4.127+
DEBUG Adding transitive dependency for torch==2.5.1: setuptools{python_full_version >= '3.12'}*
DEBUG Adding transitive dependency for torch==2.5.1: sympy{python_full_version >= '3.9'}>=1.13.1, <1.13.1+
DEBUG Adding transitive dependency for torch==2.5.1: triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'}>=3.1.0, <3.1.0+
DEBUG Adding transitive dependency for torch==2.5.1: typing-extensions>=4.8.0
DEBUG Searching for a compatible version of filelock ()
DEBUG Selecting: filelock==3.16.1 [preference] (filelock-3.16.1-py3-none-any.whl)
DEBUG Searching for a compatible version of fsspec ()
DEBUG Selecting: fsspec==2024.12.0 [preference] (fsspec-2024.12.0-py3-none-any.whl)
DEBUG Searching for a compatible version of jinja2 ()
DEBUG Selecting: jinja2==3.1.5 [preference] (jinja2-3.1.5-py3-none-any.whl)
DEBUG Adding transitive dependency for jinja2==3.1.5: markupsafe>=2.0
DEBUG Searching for a compatible version of networkx ()
DEBUG Selecting: networkx==3.4.2 [preference] (networkx-3.4.2-py3-none-any.whl)
DEBUG Searching for a compatible version of nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [preference] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cublas-cu12==<IP_ADDRESS>: nvidia-cublas-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cublas-cu12==<IP_ADDRESS>: nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cublas-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [preference] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cublas-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cublas-cu12==<IP_ADDRESS> [preference] (nvidia_cublas_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [preference] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-cupti-cu12==12.4.127: nvidia-cuda-cupti-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-cupti-cu12==12.4.127: nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [preference] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-cupti-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-cupti-cu12==12.4.127 [preference] (nvidia_cuda_cupti_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [preference] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-nvrtc-cu12==12.4.127: nvidia-cuda-nvrtc-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-nvrtc-cu12==12.4.127: nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [preference] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-nvrtc-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-nvrtc-cu12==12.4.127 [preference] (nvidia_cuda_nvrtc_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [preference] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cuda-runtime-cu12==12.4.127: nvidia-cuda-runtime-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-cuda-runtime-cu12==12.4.127: nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [preference] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cuda-runtime-cu12 (==12.4.127)
DEBUG Selecting: nvidia-cuda-runtime-cu12==12.4.127 [preference] (nvidia_cuda_runtime_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [preference] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cudnn-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cudnn-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [preference] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Searching for a compatible version of nvidia-cudnn-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cudnn-cu12==<IP_ADDRESS> [preference] (nvidia_cudnn_cu12-<IP_ADDRESS>-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-cudnn-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Searching for a compatible version of nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [preference] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-cufft-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cufft-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [preference] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cufft-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cufft-cu12==<IP_ADDRESS> [preference] (nvidia_cufft_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cufft-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [preference] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-curand-cu12==<IP_ADDRESS>: nvidia-curand-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-curand-cu12==<IP_ADDRESS>: nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-curand-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [preference] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-curand-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-curand-cu12==<IP_ADDRESS> [preference] (nvidia_curand_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [preference] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusolver-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cusolver-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [preference] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusolver-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusolver-cu12==<IP_ADDRESS> [preference] (nvidia_cusolver_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cublas-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12*
DEBUG Adding transitive dependency for nvidia-cusolver-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=<IP_ADDRESS>, <<IP_ADDRESS>+)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [preference] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12==<IP_ADDRESS>
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==<IP_ADDRESS>
DEBUG Searching for a compatible version of nvidia-cusparse-cu12 (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [preference] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-cusparse-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==<IP_ADDRESS>)
DEBUG Selecting: nvidia-cusparse-cu12==<IP_ADDRESS> [preference] (nvidia_cusparse_cu12-<IP_ADDRESS>-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-cusparse-cu12==<IP_ADDRESS>: nvidia-nvjitlink-cu12*
DEBUG Searching for a compatible version of nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=2.21.5, <2.21.5+)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [preference] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for nvidia-nccl-cu12==2.21.5: nvidia-nccl-cu12==2.21.5
DEBUG Adding transitive dependency for nvidia-nccl-cu12==2.21.5: nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==2.21.5
DEBUG Searching for a compatible version of nvidia-nccl-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==2.21.5)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [preference] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Searching for a compatible version of nvidia-nccl-cu12 (==2.21.5)
DEBUG Selecting: nvidia-nccl-cu12==2.21.5 [preference] (nvidia_nccl_cu12-2.21.5-py3-none-manylinux2014_x86_64.whl)
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [preference] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-nvjitlink-cu12==12.4.127: nvidia-nvjitlink-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-nvjitlink-cu12==12.4.127: nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12 (==12.4.127)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [preference] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-nvjitlink-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-nvjitlink-cu12==12.4.127 [preference] (nvidia_nvjitlink_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (>=12.4.127, <12.4.127+)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [preference] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Adding transitive dependency for nvidia-nvtx-cu12==12.4.127: nvidia-nvtx-cu12==12.4.127
DEBUG Adding transitive dependency for nvidia-nvtx-cu12==12.4.127: nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'}==12.4.127
DEBUG Searching for a compatible version of nvidia-nvtx-cu12{platform_machine == 'x86_64' and sys_platform == 'linux'} (==12.4.127)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [preference] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of nvidia-nvtx-cu12 (==12.4.127)
DEBUG Selecting: nvidia-nvtx-cu12==12.4.127 [preference] (nvidia_nvtx_cu12-12.4.127-py3-none-manylinux2014_aarch64.whl)
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} ()
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools==75.6.0
DEBUG Adding transitive dependency for setuptools==75.6.0: setuptools{python_full_version >= '3.12'}==75.6.0
DEBUG Searching for a compatible version of setuptools{python_full_version >= '3.12'} (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of setuptools (==75.6.0)
DEBUG Selecting: setuptools==75.6.0 [preference] (setuptools-75.6.0-py3-none-any.whl)
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (>=1.13.1, <1.13.1+)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: sympy==1.13.1
DEBUG Adding transitive dependency for sympy==1.13.1: sympy{python_full_version >= '3.9'}==1.13.1
DEBUG Searching for a compatible version of sympy{python_full_version >= '3.9'} (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of sympy (==1.13.1)
DEBUG Selecting: sympy==1.13.1 [preference] (sympy-1.13.1-py3-none-any.whl)
DEBUG Adding transitive dependency for sympy==1.13.1: mpmath>=1.1.0, <1.4
DEBUG Searching for a compatible version of triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'} (>=3.1.0, <3.1.0+)
DEBUG Selecting: triton==3.1.0 [preference] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for triton==3.1.0: triton==3.1.0
DEBUG Adding transitive dependency for triton==3.1.0: triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'}==3.1.0
DEBUG Searching for a compatible version of triton{python_full_version < '3.13' and platform_machine == 'x86_64' and sys_platform == 'linux'} (==3.1.0)
DEBUG Selecting: triton==3.1.0 [preference] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for triton==3.1.0: filelock
DEBUG Searching for a compatible version of triton (==3.1.0)
DEBUG Selecting: triton==3.1.0 [preference] (triton-3.1.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl)
DEBUG Adding transitive dependency for triton==3.1.0: filelock*
DEBUG Searching for a compatible version of typing-extensions (>=4.8.0)
DEBUG Selecting: typing-extensions==4.12.2 [preference] (typing_extensions-4.12.2-py3-none-any.whl)
DEBUG Searching for a compatible version of markupsafe (>=2.0)
DEBUG Selecting: markupsafe==3.0.2 [preference] (MarkupSafe-3.0.2-cp312-cp312-macosx_10_13_universal2.whl)
DEBUG Searching for a compatible version of mpmath (>=1.1.0, <1.4)
DEBUG Selecting: mpmath==1.3.0 [preference] (mpmath-1.3.0-py3-none-any.whl)
DEBUG Tried 24 versions: demo-torch 1, filelock 1, fsspec 1, jinja2 1, markupsafe 1, mpmath 1, networkx 1, nvidia-cublas-cu12 1, nvidia-cuda-cupti-cu12 1, nvidia-cuda-nvrtc-cu12 1, nvidia-cuda-runtime-cu12 1, nvidia-cudnn-cu12 1, nvidia-cufft-cu12 1, nvidia-curand-cu12 1, nvidia-cusolver-cu12 1, nvidia-cusparse-cu12 1, nvidia-nccl-cu12 1, nvidia-nvjitlink-cu12 1, nvidia-nvtx-cu12 1, setuptools 1, sympy 1, torch 1, triton 1, typing-extensions 1
DEBUG all marker environments resolution took 0.004s
DEBUG Reverting changes to pyproject.toml
DEBUG Removing uv.lock
error: Distribution torch==2.5.1 @ registry+https://pypi.org/simple can't be installed because it doesn't have a source distribution or wheel for the current platform

but
uv init
uv venv --python 3.12
source .venv/bin/activate
uv pip install torch

works

Thanks -- this is a duplicate of #9711 (and, e.g., https://github.com/astral-sh/uv/issues/9988). uv add will perform a universal resolution, so it will pick the most recent version of PyTorch ignoring your current platform -- and PyTorch stopped publishing x86 wheels.


⚠ Bofrost.de has degraded performance

In fb8a5d5, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 818 ms

Resolved: Bofrost.de performance has improved in d123d07.


validate policy against nodes, error if not valid

this commit aims to improve the feedback of "runtime" policy errors which would only manifest when the rules are compiled to filter rules with nodes.
this change will in;
file-based mode load the nodes from the db and try to compile the rules on start up and return an error if they would not work as intended.
database-based mode prevent a new ACL being written to the database if it does not compile with the current set of node.
Fixes #2073
Fixes #2044

Summary by CodeRabbit

New Features

Enhanced validation for Access Control List (ACL) policies to prevent runtime errors from invalid configurations.
Improved error reporting with additional context when setting policies, aiding in better issue traceability.

Bug Fixes

Resolved potential issues related to policy application by ensuring policies are validated against the current database state.
Added tests to validate error handling for invalid policy configurations, ensuring system integrity.

@pallabpain What do you think about this?

@pallabpain What do you think about this?

Sorry, I did not get a chance to look at this. I was thinking more along the lines of validating the incoming policy bytes at the time of unmarshaling it into the ACL type. But this looks good. 👍🏼


Examples targeting running app

[ ] Bump client version after successful release.
[ ] merge thruflo/quickstart first

Will address todoMVC in separate patch.

[ ] @thruflo, @icehaunter I need the migrations folder for the items-example app to put with the examples. We wait for final folder structure for that.

Made a pass, but will still require changes to config and migrations.

Required changes were merged to other branch


tmQuoteModule should return global references in dependency order, without duplicates

Why is tmQuoteModule returning duplicates?
From Coq Require Import Lists.List.
From MetaCoq.Common Require Import Kernames.
From MetaCoq.Utils Require Import bytestring monad_utils.
From MetaCoq.Template Require Import All.

Local Open Scope bs.
Import MCMonadNotation.
Import ListNotations.

Module KernameSet'. Include KernameSet. End KernameSet'.
Fixpoint duplicates (v : list global_reference) : list global_reference
  := match v with
     | nil => nil
     | v :: vs
       => if existsb (fun v' => v == v') vs
          then v :: duplicates vs
          else duplicates vs
     end.
Goal True.
  run_template_program (tmQuoteModule "KernameSet'") (fun v => pose (duplicates v) as q).
  vm_compute in q.
  (*   q := [ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "t");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "eq");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "eq_equiv");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "lt");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "lt_strorder");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "lt_compat");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "compare");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "compare_spec");
        ConstRef
          (MPdot
             (MPfile ["Kernames"; "Common"; "ToTemplate"; "Quotation"; "MetaCoq"])
             "KernameSet'", "eq_dec")] : list global_reference
  ============================
  True
*)

On Zulip, @SkySkimmer says:

the duplicates may be because of
        | SFBmodule mb -> aux mb

recursing in submodules without updating the module path mp
so f you have
Module Bla.
Module Bla'.
Definition t := ...
End Bla'.
Definition t := ...
End Bla.

quoting Bla will put Bla.t twice in the list instead of 1 Bla.t and 1 Bla.Bla'.t

Am I correct that the handling of Algebraic _ -> [] is what results in the empty list being returned for bound modules and bound aliases?

that sounds plausible
I'm not sure what the spec of this thing is but probably it should be looking at mb.mod_type all the time and ignore > mb.mod_expr
basically I think it should be something like
let rec quote_module mb : GlobRef.t list =
  let open Declarations in
  match mb.mod_type with
  | MoreFunctor _ -> [] (* current version errors, not sure what is wanted *)
  | NoFunctor fields ->
    let get_ref (label, field) =
      let open Names in
      match field with
      | SFBconst _ -> [GlobRef.ConstRef (Constant.make2 mb.mod_mp label)]
      | SFBmind _ -> [GlobRef.IndRef (MutInd.make2 mb.mod_mp label, 0)]
      | SFBmodule mb -> quote_module mb
      | SFBmodtype mtb -> []
    in
    CList.map_append get_ref fields

let quote_module qualid = quote_module (Global.lookup_module (Nametab.locate_module qualid))

This is with reference to https://github.com/MetaCoq/metacoq/blob/112caceda83cef8b7543dd3112742a70542691e0/template-coq/src/plugin_core.ml#L169-L192


[9.0.1] Blocks View.css not loaded

After updating to version 9.0.1, view.css is not loaded from all blocks.
There is no error displayed, there is nothing in the reports. Only in the frontend the view.css is not loaded.
Back in version 9.0.0 the view.css of blocks are loaded correctly.
Is this an error or do we need to change the block view.css in 9.0.1?
System is running localhost with PHP7.4.23
Caches all disabled

I'm not aware of any updates that would impact the loading of these files. What file specifically isn't being loaded?

From each block the view.css is not loaded in the frontend.
It does not matter whether the block is from a package or is in the Application/Blocks directory.
This happens with concrete blocks as well as custom blocks.
Tested with the blocks page_list and image.
Here the environment information:
`
Concrete Version
Core Version - 9.0.1
Version Installed - 9.0.1
Database Version -<PHONE_NUMBER>1958
Database Information
Version: 10.6.4-MariaDB-1:10.6.4+maria~focal
SQL Mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Concrete Packages
Webpresso-Theme
Concrete Overrides
blocks/autonav/view.php, blocks/autonav, blocks/image/view.css, blocks/image/view.php, blocks/image, blocks/page_list/templates/basic_list.php, blocks/page_list/templates, blocks/page_list/view.css, blocks/page_list/view.php, blocks/page_list, blocks/wbox_focusimg/add.php, blocks/wbox_focusimg/composer.php, blocks/wbox_focusimg/config.json, blocks/wbox_focusimg/controller.php, blocks/wbox_focusimg/db.xml, blocks/wbox_focusimg/edit.php, blocks/wbox_focusimg/fallback.jpg, blocks/wbox_focusimg/form.php, blocks/wbox_focusimg/icon.png, blocks/wbox_focusimg/raster.png, blocks/wbox_focusimg/view.css, blocks/wbox_focusimg/view.js, blocks/wbox_focusimg/view.php, blocks/wbox_focusimg
Concrete Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).
Server Software
Apache/2.4.38 (Debian)
Server API
apache2handler
PHP Version
7.4.23
PHP Extensions
apache2handler, Core, ctype, curl, date, dom, fileinfo, filter, ftp, gd, hash, iconv, imagick, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, Reflection, session, SimpleXML, sodium, SPL, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, Zend OPcache, zip, zlib
PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - -1
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
upload_max_filesize - 2M
mbstring.regex_retry_limit - 1000000
mbstring.regex_stack_limit - 100000
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - no value
session.gc_maxlifetime - 7200
unserialize_max_depth - 4096
opcache.max_accelerated_files - 10000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5
`

Same issue with me. I have a custom add-on with the normal ‘view.php’ and ‘view.css’. The add-on css loads with v8 and v9, but not v9.0.1. Had to load the css from blocks/controller using ‘register’ and ‘requireAsset’ for V9.0.1.
@webpresso: The ‘image’ and ‘page_list’ blocks don’t have a ‘view.css’ file to call.

@SB1955 Normally these blocks don't have it, however for testing I gave them each a view.css...Just to see if the problem might be with my blocks. Therefore I have attached the overview of my Enviorment, there are these overrides noted.
Which PHP version is your installation running?

Thanks everyone – I've verified this is indeed an issue. It was strange because we didn't touch anything related to this, but it terms out some sloppy variable naming/collision is the culprit. The $view string that we check is set to "view" before we load view.css, view.js, etc... was being overwritten.
Can you manually apply this commit to your installations and see if this fixes the problem?
https://github.com/concrete5/concrete5/pull/10061/commits/694c6e4b146f329225cde7a1623c75854855d962

@aembler Yes, that fixes it for me! Perfect!

Issue fixed, thanks.

Excellent. Thanks! This will be merged in shortly and will appear in 9.0.2

Could that be related to this one: https://github.com/concrete5/concrete5/issues/10069 ? Or the other way round, maybe that one is related to this one.
My investigation started from the same issue, I could see styling applied to one of my package blocks, then I've realaized the view.css was not even loaded, then I've found the other problems

@linuxoid Doubtful. In this case this was a misnamed variable that was only misnamed in the file that handles loading template assets in view mode.


Change default browser

Ability to open links in a different browser in the app other than safari would be great like Firefox or brave

Duplicate of #1231


gNMI-1.10: Remove missing hw port deviation

This PR removes missing -deviation_missing_interface_hardware_port

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.785%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1191

Relevant Lines:
2135

💛  - Coveralls

/gcbrun

b/281732797 has the internal test results.


Manually add EOD to LTS notes

@lluiscampos
Updated the commit signature.
Seems to be failing for unrelated reasons now:
ERROR: for mender-device-auth  Head "https://registry.mender.io/v2/mendersoftware/deviceauth-enterprise/manifests/staging": no basic auth credentials
ERROR: for mender-deployments  Head "https://registry.mender.io/v2/mendersoftware/deployments-enterprise/manifests/staging": no basic auth credentials
ERROR: for mender-workflows-server  Head "https://registry.mender.io/v2/mendersoftware/workflows-enterprise/manifests/staging": no basic auth credentials
ERROR: for mender-useradm  Head "https://registry.mender.io/v2/mendersoftware/useradm-enterprise/manifests/staging": no basic auth credentials
ERROR: for mender-inventory  Head "https://registry.mender.io/v2/mendersoftware/inventory-enterprise/manifests/staging": no basic auth credentials


Add the Compress function (#4)

Add the Compress function (#4)

running over the selector will result in a "panic: runtime error: index out of range", not sure how this wants wants to be handled if at all, left it as default for now

added a selector len check to stop panic in prev comment, i will also add a benchmark test in


Fix NoMethodError when trying to get AST of a Builder's result.

In the first pair of commits of the PR there are a couple of shared examples and updates of the Dry::Logic::Builder's unit specs which reproduces a raised exception in scenarios like the following :
Dry::Logic::Builder.() { key?(:speed) }.to_ast
#     NoMethodError:
#       undefined method `name' for #<Proc:0x000000010c8982a0 (lambda)>
#
#                 predicate.name
#                          ^^^^^

This is fixed by an avoiding of extra predicate to proc coercion in Dry::Logic::Builder::Context#initialize. So now it is just passed into the Dry::Logic::Builder::Context#predicate which lets to keep a predicate's name.

👀

@estum thank you!


xExchMailboxDatabase [1.31.0]: All Parameters Have Type Errors

Details of the scenario you tried and the problem that is occurring
I am probably missing something easy but it seems that all parameters of xExchMailboxDatabase return type errors. All other resources are working fine. For example:

Cannot process argument transformation on parameter 'Bool2'. Cannot convert value "System.Object[]" to type "System.Nullable`1[System.Boolean]". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.

If we comment out boolean parameters, we see the same for TimeSpan:

Cannot process argument transformation on parameter 'TimeSpan'. Cannot convert value "System.Object[]" to type "Microsoft.Exchange.EnhancedTimeSpan".

If we comment out TimeSpan parameters, we see the same but referring to a string.
Verbose logs showing the problem
Logs for a boolean error:

VERBOSE: [CA1-TST-EX01]: LCM:  [ Start  Resource ]  [[xExchMailboxDatabase]MXDB-CA1-2019]
VERBOSE: [CA1-TST-EX01]: LCM:  [ Start  Test     ]  [[xExchMailboxDatabase]MXDB-CA1-2019]
VERBOSE: [CA1-TST-EX01]:                            [[xExchMailboxDatabase]MXDB-CA1-2019] Entering function 'Test-TargetResource'. Notable parameters: Name = 'MXDB-CA1-2019'
VERBOSE: [CA1-TST-EX01]:                            [[xExchMailboxDatabase]MXDB-CA1-2019] Reusing existing Remote PowerShell Session to Exchange
Cannot process argument transformation on parameter 'Bool2'. Cannot convert value "System.Object[]" to type "System.Nullable`1[System.Boolean]". Boolean parameters accept only Boolean values and
numbers, such as $True, $False, 1 or 0.
At C:\source\TechnologyInfrastructure\dsc_output\Start-Configuration.ps1:31 char:5

Start-DscConfiguration -ComputerName $MachineId -Force -Wait -Pat ...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : InvalidData: (:) [], CimException
FullyQualifiedErrorId : ParameterArgumentTransformationError,Compare-BoolToBool

Cannot process argument transformation on parameter 'Bool2'. Cannot convert value "System.Object[]" to type "System.Nullable`1[System.Boolean]". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.

Suggested solution to the issue
Any help would be appreciated.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The configuration data for the databases is:
@{
    NodeName = "CA1-TST-EX01"
    DAGRole = "AdditionalDAGMember"
    DAGID = "DAG1"
    PrimaryDBList = @{
        MBXDBCA1 = @{Name = 'MXDB-CA1-2019'; EdbFilePath = "M:\Data\MXDB-CA1-2019\MXDB-CA1-2019.edb"; LogFolderPath = "L:\Logs\MXDB-CA1-2019\MXDB-CA1-2019.log"};
    }

    CopyDBList    = @{
        MBXDBUK1 = @{Name = 'MXDB-UK1-2019'; ActivationPreference = 2; ReplayLagTime = '00:00:00'};
    }
}
@{
    NodeName = "UK1-TST-EX01"
    DAGRole = "FirstDAGMember"
    DAGID = "DAG1"
    PrimaryDBList = @{
        MBXDBUK1 = @{Name = 'MXDB-UK1-2019'; EdbFilePath = "M:\Data\MXDB-UK1-2019\MXDB-UK1-2019.edb"; LogFolderPath = "L:\Logs\MXDB-UK1-2019\MXDB-UK1-2019.log"};
    }

    CopyDBList    = @{
        MBXDBCA1 = @{Name = 'MXDB-CA1-2019'; ActivationPreference = 2; ReplayLagTime = '00:00:00'};
    }
}

The resource is configured as follows:
foreach ($DB in $Node.PrimaryDBList.Values)
{
    xExchMailboxDatabase $DB.Name
    {
        Name = $DB.Name
        EdbFilePath = $DB.EdbFilePath
        LogFolderPath = $DB.LogFolderPath
        Server = $Node.NodeName
        CircularLoggingEnabled = $true
        IssueWarningQuota = "7GB"
        ProhibitSendQuota  = "Unlimited"
        ProhibitSendReceiveQuota = "Unlimited"
        DeletedItemRetention = "14.00:00:00"
        MailboxRetention = "30.00:00:00"
        AllowServiceRestart = $true
        MountAtStartup = $true
        DatabaseCopyCount = 4
        Credential = $AdminCredentials
    }
}

Exchange Server edition and version the target node is running
Exchange Server 2019 CU5 Enterprise
Version 15.2 (Build 595.3)
The operating system the target node is running
OsName                            Microsoft Windows Server 2019 Standard
OsOperatingSystemSKU   StandardServerEdition
OsArchitecture                  64-bit
WindowsVersion               1809
WindowsBuildLabEx          17763.1.amd64fre.rs5_release.180914-1434
OsLanguage                      en-US
OsMuiLanguages              {en-US}
Version and build of PowerShell the target node is running
PSVersion                        5.1.17763.1007
BuildVersion                   10.0.17763.1007
Version of the DSC module that was used
xExchange 1.31.0  C:\Program Files\WindowsPowerShell\Modules\xExchange\1.31.0\xExchange.psd1

Thanks for the report @acstyche . Tagging @SSvilen for awareness since he's done recent work in the affected area. Looks like this may be due to the change in how the Remote Exchange Session is created, or one of the recent changes in xExchMailboxDatabase.

Hi @mhendric,
actually all of my changes in the last month or so are getting released as preview. 1.32.0-preview004 is the latest. I think you should set a tag in the git commit, in order to do an official 'release'. So this bug refers to version 1.31.0, which is the version we released after moving to Azure DevOps.

Hi @mhendric and @SSvilen,
Please let me know if I can provide any additional information or try anything out to help.

@acstyche ,
can you try with 1.32.0-preview004 version?

Hi @SSvilen,
Yeah, we can try that. Will take a bit to get this set up in our test environment but will let you know how it goes.

thanks @acstyche. I'll try it tonight in my home lab too (althought I have do)

That definitely has to do with version 1.31 - the Get-MailboxDatabaseInternal has a bug and it gives back all databases - that's why it#s complaining that it can not covert an array (System.Object[]) to Bool or timespan or whatever.
@mhendric - do you think we can now release version 1.32?

Thanks a lot for the update @SSvilen! We have added the preview version to our ProGet (which brought up some PowerShellGet versioning issues and will need some environment tweaks). Will hopefully be able to test today and let you know how it goes.

@SSvilen, yes, 1.3.2 worked for xExchMailboxDatabase!
However, was something changed with xExchSendConnector? It was working fine but is now throwing an error  on set:

VERBOSE: [CA1-TST-EX01]:                            [[xExchSendConnector]ProductionExchange] Creating send connector mail.orbis.com Production Exchange.

Saying "The object...already exists." Shouldn't the test have detected this?

VERBOSE: [CA1-TST-EX01]:                            [[xExchSendConnector]ProductionExchange] Send Connector should exist, but does not.

@SSvilen , to be honest, I'm not sure what the release cadence for official releases is supposed to be any more. I don't see an issue, other than that if the latest build has a major bug in xExchSendConnector, we may want to resolve that first. Adding @johlju and @gaelcolas for insight on when/how to do a new release.

@mhendric you as a maintainer decide when to release a full version. The pipeline now uses continuous delivery so every merge to master will release a new preview version. To release a full release a tag should be pushed, see the Release section in the maintainer guidelines https://dsccommunity.org/guidelines/maintaining/

Hello all,
Just as an update, we pointed back to 1.31.0 and xExchSendConnector ran successfully again.
Please let me know if you need any more information.

Actually, subsequent applications of xExchSendConnector fail, with a different error, in 1.31.0. Even using a previously successful deployment. But only on the first server in the deployment. The deployment succeeds on the second server, with both having the same settings.
The error is different than the one in 1.32.0-preview004. Do you want me to create a new issue or post the logs here?

Hi @acstyche ,
please open another problem tracker for the send connector. But tbh I'm using send connector resource in production and never faced any problems. May be there is a problem with one of your servers?
I'll check exactly what  I have as configurations in my prod and test env and which version of xExchange I'm using.
@mhendric ,
let's wait and see if the send connector also has a problem in it and then you can decide whether to publish a new version or not.

Haha...yes, given the amount of changes to the server while testing, that is actually very likely. It does work on the other servers on 1.31.0. Not on 1.32.0-preview004.
We are going to remove Exchange from that server and revert it to a base image to start again. Will open a new issue if necessary.
Thanks.

@acstyche,
So the mailboxdatabase resource is working fine for you now? And the problem with the send connector resource is what you mentioned in #452 ? No other problems observed on your side?
@mhendric,
I'll open today 2 PRs, which contain only one-line changes and  I believe we should publish version 1.32 officially.

Hi @SSvilen, thanks for sorting #452.
Has the xExchSendConnectors issue in 1.32.0-preview0004 been fixed, where it doesn't detect the send connectors are already set up? I can create an issue for that too, if you want?

@acstyche,
I can not reproduce the problem you are experiencing. Just created and tested new send connector. Can you show me your config?

Sure:
xExchSendConnector ProductionExchange {     Name = $Node.ProdSendConnector     Ensure = "Present"     AddressSpaces = $Node.ProdAddressSpace     ConnectionInactivityTimeout = "00:10:00"     ConnectorType = "Default"     DNSRoutingEnabled = $false     DomainSecureEnabled = $false     Enabled = $true     ErrorPolicies = "Default"     ForceHELO = $false     FrontendProxyEnabled = $false     IgnoreSTARTTLS = $false     IsScopedConnector = $false     MaxMessageSize = $Node.MaxMessageSize     Port = "25"     ProtocolLoggingLevel = "None"     RequireTLS = $false     SmartHostAuthMechanism = "None"     SmartHosts = "mail.orbis.com"     SmtpMaxMessagesPerConnection = "20"     SourceIPAddress = "<IP_ADDRESS>"     SourceTransportServers = $Node.SourceTransport     UseExternalDNSServersEnabled = $false     Credential = $AdminCredentials }
You can see the test doesn't detect it:

VERBOSE: [CA1-TST-EX01]:                            [[xExchSendConnector]ProductionExchange] Importing function 'Get-SendConnector'.
VERBOSE: [CA1-TST-EX01]:                            [[xExchSendConnector]ProductionExchange] Send Connector should exist, but does not.
VERBOSE: [CA1-TST-EX01]: LCM:  [ End    Test     ]  [[xExchSendConnector]ProductionExchange]  in 2.0710 seconds.

But then it tries to create it and fails because it's already there:

VERBOSE: [CA1-TST-EX01]:                            [[xExchSendConnector]ProductionExchange] Importing function 'Set-SendConnector'.
VERBOSE: [CA1-TST-EX01]:                            [[xExchSendConnector]ProductionExchange] Creating send connector mail.orbis.com Production Exchange.
Active Directory operation failed on DC-VC1.ad.orbis.im. The object 'CN='I removed the name' already exists.

Sorry, just to add this does not happen in 1.31.0.

Hey @SSvilen and @acstyche , all of @SSvilen 's PR's have been merged. I wanted to sync back up with you and see how you two are feeling about the stability of the module at this point. Think we're ready to push an official release?

@acstyche ,
what happens when you do:
$name = 'mail.orbis.com Production Exchange'
Get-SendConnector -ErrorAction SilentlyContinue | Where-Object -Property 'Identity' -eq $Name

on that CA1-TST-EX01 server?
@mhendric ,
I'll git the new preview version a try tomorrow  in my test env at work and if case of problems, I'll just open a PR.

Hi @SSvilen, will give that a try tomorrow.
The name of the resource is in verbose, the name of the actual send connector contains our domain info, so was removed.

Hi @SSvilen, that returns the send connector, as expected. If you can't reproduce the issue, I'm fine with moving forward with 1.32.0. It is probably something squirrelly with our config we need to dig into. We also aren't too concerned with xExchSendConnector, xExchMailboxDatabase is much more important.
Thanks for taking a look!

OK @acstyche, the other thing you can try is to debug the DSC config. link
That way you can see what exaclty get-targetresource returns and why the test-targetresource is failing.
@mhendric,
I've tested the new preview - the commit for xExchAddressList was not included, but otherwise everything works as expected.

@johlju , I just created a new tag via the Release instructions in the Maintainer Guidelines. Can you confirm whether everything has been done correctly for this release? Not sure if I need to manually combine the Added / Changed notes from all the previews, or if automation will handle that. Also not sure if I need to do anything for this to be pushed to PowerShellGallery.

You can follow the build here https://github.com/dsccommunity/xExchange/commits/master on the latest commit. It starts with an orange dot and then goes to a green checkmark when all the pipeline steps have ran. The pipeline will make a github release, and deploy to the gallery automatically. It will also get the correct change log entries into the releases. It will finally send a PR with the update change log.
In this case one of the deploy steps failed (red x). I'm looking at why. If you click on the red x you can click your way to the Azure Pipeline and see what happened.

Scratch that. It runs https://dev.azure.com/dsccommunity/xExchange/_build/results?buildId=1989&view=results

Not sure why I can't see it from the commit history on master (as mentioned above)

Ah the previous build failed on the deploy step for that commit, that is why is shows a red x instead of the orange dot. Hopefully the deploy step will pass once the release build you triggered gets to the deploy step. Currently it is running tests.

@mhendric all good! It was released successfully, you did it perfectly.
https://dev.azure.com/dsccommunity/xExchange/_build/results?buildId=1989&view=logs&j=5d0a9c4e-8741-5118-af45-406a30fe661c&t=bda0b158-a237-516f-c1d0-31339587c5b5
https://www.powershellgallery.com/packages/xExchange/1.32.0

Thanks @johlju ! The steps to do a Release felt almost too simple. I thought I had to be missing something :)

It is very simple and fast to release now! 😄

Thanks a lot all! Hoping to test the release today or tomorrow.

All looks good, thanks a lot for getting this sorted.


[Bug Report] type="week" does not select startDate of week.

Element UI version
2.3.8
OS/Browsers version
OS X 10.11.6 / google chrome 66.0.3359.181
Vue version
2.5.16
Reproduction Link
https://jsfiddle.net/ms50he6d/
Steps to reproduce
1.click week date-picker
2. change other week
3. value become second date of week
What is Expected?
to select start date of week.
What is actually happening?
data-picker which type is week does not select start date of week.
please show Reproduction Link and select date of week data-picker.  when you select other week, v-modal's value is second date of week.

Duplicate of #6754


Permanent startup errors in Windows Events

Every time I start my machine, I'm getting the following two errors in Windows Events, always together (after one another):
Event 1026
Application: SPDIFKA.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Xml.XmlException
at System.Xml.XmlTextReaderImpl.Throw(System.Exception)
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Configuration.XmlUtil..ctor(System.IO.Stream, System.String, Boolean, System.Configuration.ConfigurationSchemaErrors)
at System.Configuration.BaseConfigurationRecord.InitConfigFromFile()
Exception Info: System.Configuration.ConfigurationErrorsException
at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean)
at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(System.Configuration.ConfigurationSchemaErrors)
at System.Configuration.ClientConfigurationSystem.OnConfigRemoved(System.Object, System.Configuration.Internal.InternalConfigEventArgs)
Exception Info: System.Configuration.ConfigurationErrorsException
at System.Configuration.ConfigurationManager.PrepareConfigSystem()
at System.Configuration.ConfigurationManager.get_AppSettings()
at System.Windows.Forms.DpiHelper.Initialize()
Exception Info: System.TypeInitializationException
at SPDIFKA.SPDIFKAGUI..ctor()
at SPDIFKA.SPDIFKA.Main()
and Event 1000 (100)
Faulting application name: SPDIFKA.exe, version: <IP_ADDRESS>, time stamp: 0x58ca0a39
Faulting module name: KERNELBASE.dll, version: 6.1.7601.24150, time stamp: 0x5b0cbc65
Exception code: 0xe0434352
Fault offset: 0x000000000001a06d
Faulting process id: 0x1214
Faulting application start time: 0x01d417136f03ace5
Faulting application path: C:\Program Files (x86)\SPDIFKA\SPDIFKA.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: ad787c5c-8306-11e8-a49f-c8600017ee38
The SPDIF-KA seems to be running though after that, but I wonder why this is happening and if I should be concerned about it. Of course, it's not nice that it's filling my Events log, but ... I can live with that if it doesn't indicate some malfunction. Please advise.

I had similar issue - In my case SPDIFKA logged this error and immediately crashed.
Resolved by deleting config file in C:\Users\%username%\AppData\Local\handruin.com - the file got propadly corrupted during recent BSOD.


Gitlab - abaplint for commited objects only

Hi, I don't know if this is the right approach but I managed to do a pipeline in GitLab which is triggered for every commit and it gives list of issues only in these, commited, objects.
I know this probably looks messy for DevOps but I am not one.
abaplint_commit_only:
    image: abaplint/abaplint
    stage: test
    script:
        - git diff-tree --no-commit-id --name-only -r $CI_MERGE_REQUEST_TARGET_BRANCH_SHA -r $CI_COMMIT_SHA > commited.txt
        - git ls-files > files.txt
        - grep -Fvxf commited.txt files.txt > exclude.txt
        - sed -e 's/^/"/' -e 's/$/"/' -e '$!s/$/,/' exclude.txt > exclude_final.txt
        - wget https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64
        - chmod +x jq-linux64
        - sed $'/###NOISSUES###/{r exclude_final.txt\nd}' abaplint_template | ./jq-linux64 . > abaplint_commited.json
        # - cat abaplint_commited.json
        - abaplint abaplint_commited.json --outformat junit --outfile report_commit.xml
    artifacts:
        reports:
            junit: report_commit.xml

abaplint_template fragment which is relevant
...
"global": {
        "exclude": [],
        "noIssues" : [
        ###NOISSUES###
        ],
...

closing


Update docker image tags

confluentinc/confluent-local: 7.6.0 -> 7.6.1
library/mongo: 7.0.5 -> 7.0.8
qdrant/qdrant: 1.8.3 -> 1.8.4

(cherry picked from commit 7994886

Update docker image tags
Update versions in playground, tests, and xml docs

Microsoft Reviewers: Open in CodeFlow

For future reference next time we need to do this, how do you find which to update and what to update them to? I assume not by manually browsing the registry. Is there a docker command? is there any alternative to us just periodically repeating this exercise (ie., there's no dependabot like in this context)

We could potentially script it by putting marker comments on the lines and then having a script go through and update the files directly? The Azure SDK team did things like this:
https://github.com/Azure/azure-sdk-for-java/blob/3c12cc42b7f29ed7e72c2742297a0519a40d8974/sdk/eventhubs/azure-messaging-eventhubs/docs/pom.xml#L23


Automatically start at login

Add a checkbox to toggle this in the right-click menu.

Done in https://github.com/hmarr/vitals/commit/56d7aafc0b83380a3d285743d2585d31eb47b679


[Vue warn]: Property or method "nativeEvent" is not defined on the instance but referenced during render.

Version
2.6.14
Reproduction link
https://www.npmjs.com/package/vue
Steps to reproduce
[Vue warn]: Property or method "nativeEvent" is not defined on the instance but referenced during render. Make sure that this property is reactive, either in the data option, or for class-based components, by initializing the property.  Make sure that this property is reactive, either in the data option, or for class-based components, by initializing the property. See: https://vuejs.org/v2/guide/reactivity.html#Declaring-Reactive-Properties.
What is expected?
No warn, read this.$el normally.
What is actually happening?
Cannot read this.$el, even use ref, but can read the child element of the component.

Follow the bug reporting guidelines and provide a boiled down repro when reporting a bug in a new issue.
Or use the chat or forum to ask questions


Charms standardisation

Context
The MLOps team maintains a big number of charms that do not seem to follow any coding style and standard, and even manifest files are located in different directories in the src of the charm. We should propose a standard to follow in terms of coding style and repo organisation, same goes for CI, testing, and documentation.
The MLOps team should provide a standard for their charms, so it’s easier to maintain, automate, update, and even create charms. This story includes:

Having a coding style for charm code (the base charm may have a big impact here if we decide to use it), this includes, but is not limited to exception handling, event handling, and error handling.

For event handling in particular, we should provide best practices for the following, as those have been the reason for some of our bugs lately:

Charm removal
Charm upgrade
Charm update status
Charm health checks
Relation broken events

Having a standard for tests as we have two styles: unittest and pytest. A re-usable library can also help here.

Having a standard for what we test. Some charms have unit and individual integration tests, but some others don't have integration tests. At the moment we don't have a guideline for it.

Having a standard for which versions to test against in integration tests. For instance, should all integration tests deploy the latest/edge versions of other charms for running integration testing? Should we use a stable version?

Charms READMEs and CONTRIBUTINGs

For README.md, we have the following styles:

training-operator with some info
kserve-operators with a lot of info on how to use the charm, and then this section, which is not there in all repos
kubeflow-volumes with just enough information about the charm and how to deploy it

For CONTRIBUTING.md we only have the file in a number of repositories, and because of that there is not a standard. We have one for training-operator.

Directories are not the same across repositories. While it is understandable that not all repositories will need the same number of directories (apart from the charm's directories) we should agree on a standard for all as:

Some have templates/, others have manifests/
Some have files/
Some have assets/

What needs to get done

Identify the best practices for writing Charmed Kubeflow charms and make that a standard (could be with re-usable charm components)
Find the best practices for event handling and make that a standard. This requires the team to define and agree on what is going to be done by each (in the past, there has been disagreement on some like update status, remove, etc.)
Define the testing framework to use and make that a standard in all repositories.
Define testing standards around integration testing.
Make all README and CONTRIBUTING files have at least standard information that can be found in all charms.

Definition of Done
Charm repositories share the same structure, coding, and testing style.

Another thing we could standardize is how we name dev branches (the branches we use when we want to land more than one PR into a common feature or dev branch, test them together, and then do a final PR against main later).  As is, dev branches don't have a standard and thus they don't have branch protection (anyone can push a commit directly to a dev branch, leading to potential mistakes).  If we named them say dev/xxx, we could have branch protections (like with main and track/) on all repos

our repo settings themselves are also not standardized.  There's automation (see obs) that can make this programatically defined (this might be out of scope - its more charm repo standardization)

https://github.com/canonical/kubeflow-ci/issues/125 is also relevant here

Also relevant is https://github.com/canonical/kubeflow-ci/issues/127, which suggests we should have automation enforce the standardizations and conventions we decide on

In an attempt to also make our charms aware of the status and health of their services, we must agree on a correct approach to make sure our charms report back their actual status and act in the event of a failure. At least we have to discuss:

Having pebble health checks in all our charms.
Having other health checks for the workloads or k8s resources.
What to do in the event of a failure.

https://github.com/canonical/admission-webhook-operator/issues/123 relates to and supports this story. That issue describes some errors in the pebble health checks, and asks questions about what should be the way to resolve and carry on with issues.

The logging story in our CI is also inconsistent. Though we have things like canonical/kubeflow-ci/actions/dump-charm-debug-artifacts@main in some of our workflows, in reality it's not everywhere and we had instances of that reusable workflow not providing correct logs or missing on important details.


zero_copy: Option fields cause alignment corruption

Given the following schema:
    #[account(zero_copy)]
    pub struct AccountData {
        pub latest_confirmed_round: AggregatorRound,
        pub current_round: AggregatorRound,
        pub job_pubkeys_data: [Pubkey; 16],
        pub job_pubkeys_size: u32,
    }
    #[zero_copy]
    #[derive(Default)]
    pub struct AggregatorRound {
        pub medians_data: [Option<Decimal>; 32],
    }
    #[zero_copy]
    #[derive(Default)]
    pub struct Decimal {
        pub mantissa: i128,
        pub scale: u32,
    }

Attempting to set job_pubkeys_size or job_pubkeys_data does not function properly. But, when pub medians_data: [Option<Decimal>; 32], is removed from AggregatorRound, the fields behave normally.  I believe the Option field is causing alignment corruption on items that sit after it in memory for zero copy structures.

To note, changing:
    #[zero_copy]
    #[derive(Default)]
    pub struct AggregatorRound {
        pub medians_data: [Option<Decimal>; 32],
    }

to:
    #[zero_copy]
    #[derive(Default)]
    pub struct AggregatorRound {
        pub medians_data: [SwitchboardDecimal; 32],
        // Optionals do not work on zero_copy. Keep track of which responses are
        // fulfilled here.
        pub medians_fulfilled: [bool; 32],
    }

does resolve the issue.

Out of interest, can you try COption? https://docs.rs/solana-program/1.7.11/solana_program/program_option/enum.COption.html

Error: Type not found: {"type":{"defined":"COption<Decimal>"}}


add HP 48 RPL

Adding a language

[ ok] The code displays "Hello World"
[ ok] I have updated the readme to include the new language
[ ok] I have incremented the language count in the readme
[ ok] I have no association with the language
[ ok] There are no copyright issues with this code

Link to programming language:
https://en.wikipedia.org/wiki/HP_48_series#Programming

I also added the assembly mips for linux o32


update some project metadata

The links to SCM and JIRA are either broken or redirect to GitHub, fixed that.
Note that some other stuff, such as metadata from the parent POM, or the maven-changes-plugin configuration still need updating.

partial commit for issue and ci management


Automator: update proxy@master in istio/istio@master

Generated by Automator - 2021-02-23T07:34:10+00:00

@istio-testing: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
284423f57860dc7bbffb30e6e8c5556255dc455b
link
/test integ-security-k8s-tests_istio

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

@istio-testing: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
284423f57860dc7bbffb30e6e8c5556255dc455b
link
/test integ-security-k8s-tests_istio

lint_istio
284423f57860dc7bbffb30e6e8c5556255dc455b
link
/test lint_istio

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

/retest


Event Times are wrong

check this event out : https://opencollective.com/secure-scuttlebutt-consortium/events/js-getter-setter-abstractions-with-andre-staltz-12314ev
Andre is hosting this webinar, he lives in Finland, and the event is at 9am there.
Mix lives in New Zealand and he's about to get on the call at the time the event is listed on this page - 9AM

solution:
here's the code I use for this problem in scuttlebutt/patchbay (which is an electron / chrome env)
var spacetime = require('spacetime')

function Time (date) { // e.g. date = new Date(2019, 05, 26)
  const t = spacetime(date)
  return h('div.time', [
    t.format('nice'),
    h('div.zone', { title: 'timezone' }, [
      getTimezone() || '??',
      h('span', ['(UTC ', getTimezoneOffset(), ')'])
    ])
  ])
}

function getTimezoneOffset () {
  const offset = new Date().getTimezoneOffset() / -60
  return offset > 0 ? `+${offset}` : offset
}
getTimezone () {
  try {
    return Intl.DateTimeFormat().resolvedOptions().timeZone
  } catch (e) {
    return undefined
  }
}

the vibe of this is "have a stab at the local time" AND also tell people what we think we've guessed the timezone to be ... and tell people if we don't know for sure! I don't know about the
see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat for support of that API

I think it's important to first always display the timezone.
Then we calculate local time, and if it's different, we can add the time in the user timezone.

recommend you / a designer draws a scamp (mock up on an envelope) so the person fixing this know what you mean - timezones are curly!

Just to add a bit of feedback, I'm not able to use Open Collective events for OSC's maintainer support calls because the time zones are too unclear. We have people in 8 different time zones and I can't figure out if I should be specifying the time in my own time zone or what the users will see, and it's too confusing.

🏆 This issue was completed by @Rexben001  as part as our first Hackathon.
I retroactively added a $200 bounty on it. To claim the bounty, you can either:

Submit an invoice to https://opencollective.com/engineering/expenses/new (please mention the issue number in the expense's title)
Or ask for an Open Collective gift card of the same value (to donate to other collectives)

awesome work @Rexben001 !

@znarf it'd be great for bug reporters to get some thanks / acknowledgement. I took 5-10 mins out of my time to try and clearly outline this problem. I don't need money, I hope to benefit from this, but a high-five, and a cute emoji would co a long way e.g.

Great catch, thanks @mixmix :egg: :pineapple: :boom:

Emoji's are a really light-weight way convey playfulness and feelings without having to write heaps. This makes me feel good about contributing, because I feel like I've been seen, which makes me more likely to do the same in the future :heart:

@mixmix  thank you, you're absolutely right, we never thank enough the bug reporters. 🍍❤
Fyi, we're still working on it as I realized we should let events creators set/edit the timezone https://github.com/opencollective/opencollective/issues/2512

:tropical_fish: :heart:

Closing it, we will track the rest in the follow up issue.


Bump go version

Committer details

Local-Branch: main

Related changes

Future changes

Bump go-git client version to 5.9.0 (#24)

bump github client version (#25)

Why is the workflow 1.21 and the gomod 1.20?

To keep a bit of backward compatibility.
If a foreign module wants to import maiao, then it can, down to version 1.20