Installing PyTorch from default conda command

Checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example
pixi global install pytorch torchvision torchaudio pytorch-cuda=12.1 -c pytorch -c nvidia

Issue description
Attempting to install PyTorch on Python 3.11 results in failure, due to a package not being detected
..........
would require
0.478   │    └─ blas * mkl, for which no candidates were found.

Expected behavior
Pytorch installs correctly
This is likely related to #1484

I have the same issue. The following pixi.toml install only PyTorch CPU:
[project]
name = "pixi-cuda"
version = "0.1.0"
description = "Add a short description here"
authors = ["Tim-Oliver Buchholz"]
channels = ["nvidia", "conda-forge", "pytorch"]
platforms = ["linux-64"]

[tasks]
check_cuda = 'python -c "import torch; print(torch.cuda.is_available())"'

[system-requirements]
cuda = "11"

[dependencies]
python = "3.12.*"
pytorch-cuda = ">=11.4,<12"
pytorch = ">=2.3.1,<2.4"

pixi list | grep torch:
libtorch           2.3.1       cpu_mkl_h0bb0d08_100       47.5 MiB   conda  libtorch-2.3.1-cpu_mkl_h0bb0d08_100.conda
pytorch            2.3.1       cpu_mkl_py312h3b258cc_100  23.3 MiB   conda  pytorch-2.3.1-cpu_mkl_py312h3b258cc_100.conda
pytorch-cuda       11.8        h7e8668a_5                 3.5 KiB    conda  pytorch-cuda-11.8-h7e8668a_5.tar.bz2

I can work around it by installing PyTorch via PIP:
[project]
name = "pixi-cuda"
version = "0.1.0"
description = "Add a short description here"
authors = ["Tim-Oliver Buchholz"]
channels = ["nvidia", "conda-forge", "pytorch"]
platforms = ["linux-64"]

[tasks]
check_cuda = 'python -c "import torch; print(torch.cuda.is_available())"'

[system-requirements]
cuda = "11"

[dependencies]
python = "3.12.*"

[pypi-dependencies]
torch = "*"

[pypi-options]
extra-index-urls = ["https://download.pytorch.org/whl/cu118"]

pixi list | grep torch:
torch                     2.3.1+cu118                      1.6 GiB    pypi   torch-2.3.1+cu118-cp312-cp312-linux_x86_64.http.whl

Okay, the workaround stops working as soon as I add any other dependency like pytorch-lightning:
pixi.toml:
[project]
name = "pixi-cuda"
version = "0.1.0"
description = "Add a short description here"
authors = ["Tim-Oliver Buchholz"]
channels = ["nvidia", "conda-forge", "pytorch"]
platforms = ["linux-64"]

[tasks]
check_cuda = 'python -c "import torch; print(torch.cuda.is_available())"'

[system-requirements]
cuda = "11"

[dependencies]
python = "3.12.*"
pytorch-lightning = ">=2.3.0,<2.4"

[pypi-dependencies]
torch = "*"

[pypi-options]
extra-index-urls = ["https://download.pytorch.org/whl/cu118"]

pixi list | grep torch:
libtorch             2.3.1         cpu_mkl_h0bb0d08_100       47.5 MiB   conda  libtorch-2.3.1-cpu_mkl_h0bb0d08_100.conda
pytorch              2.3.1         cpu_mkl_py312h3b258cc_100  23.3 MiB   conda  pytorch-2.3.1-cpu_mkl_py312h3b258cc_100.conda
pytorch-lightning    2.3.0         pyhd8ed1ab_0               432.1 KiB  conda  pytorch-lightning-2.3.0-pyhd8ed1ab_0.conda
torchmetrics         1.4.0.post0   pyhd8ed1ab_0               341.9 KiB  conda  torchmetrics-1.4.0.post0-pyhd8ed1ab_0.conda

And another update. Looks like this is related to the channel order. If I set channels = ["nvidia", "pytorch", "conda-forge"] it works.

[project]
name = "pixi-cuda"
version = "0.1.0"
description = "Add a short description here"
authors = ["Tim-Oliver Buchholz"]
channels = ["nvidia", "pytorch", "conda-forge"]
platforms = ["linux-64"]

[tasks]
check_cuda = 'python -c "import torch; print(torch.cuda.is_available())"'

[system-requirements]
cuda = "11"

[dependencies]
python = "3.12.*"
pytorch-lightning = ">=2.3.0,<2.4"
pytorch = ">=2.3.1,<2.4"
pytorch-cuda = "11.8.*"

pixi list | grep torch:
pytorch              2.3.1         py3.12_cuda11.8_cudnn8.7.0_0  1.6 GiB    conda  pytorch-2.3.1-py3.12_cuda11.8_cudnn8.7.0_0.tar.bz2
pytorch-cuda         11.8          h7e8668a_5                    3.5 KiB    conda  pytorch-cuda-11.8-h7e8668a_5.tar.bz2
pytorch-lightning    2.3.0         pyhd8ed1ab_0                  432.1 KiB  conda  pytorch-lightning-2.3.0-pyhd8ed1ab_0.conda
pytorch-mutex        1.0           cuda                          2.8 KiB    conda  pytorch-mutex-1.0-cuda.tar.bz2
torchmetrics         1.4.0.post0   pyhd8ed1ab_0                  341.9 KiB  conda  torchmetrics-1.4.0.post0-pyhd8ed1ab_0.conda

This gets even more complicated if you want to add opencv to the mix. With the above channel order (["nvidia", "pytorch", "conda-forge"]) we get:
pixi run check_cuda
  ⠖ cuda:linux-64        [00:00:01] resolving conda                                                                                × failed to solve the conda requirements of 'default' 'linux-64'
  ╰─▶ Cannot solve the request because of: The following packages are incompatible
      └─ opencv >=4.10.0,<4.11 cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py312h131ea51_601, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         │           └─ ffmpeg 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 |
      6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 | 6.1.1 is excluded because due to strict channel priority not using this option from: 'https://conda.anaconda.org/conda-forge/'
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py311h5a6cdeb_601, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py310hd1140c8_601, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         │           └─ ffmpeg 7.0.1 | 7.0.1 | 7.0.1 | 7.0.1 | 7.0.1 | 7.0.1 | 7.0.1 | 7.0.1 is excluded because due to strict channel priority not using this option from: 'https://conda.anaconda.org/conda-
      forge/'
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py39hb60e6cd_601, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py38heac1b63_601, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py39ha1d3367_601, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py312h21e1ac6_600, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py311h5fdf532_600, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py310hbbd9133_600, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py39h0ffffb9_600, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py38hb11e753_600, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt6_py39h33f55d2_600, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py312h23c775b_501, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py311h27bda42_501, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py310h1a23324_501, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py39h6d5955e_501, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py38h6e305d6_501, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py39h75a1c2e_501, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py312hdcfb50f_500, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py311h4b374c5_500, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py310hee144ac_500, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py39h678e54b_500, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py38hbe4c39b_500, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 qt5_py39hf0b7c19_500, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py312hc5075ff_1, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py311h5bd7e75_1, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py310h3d4b477_1, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py39h2f75a73_1, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py38h909be62_1, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py39h4ebaf0d_1, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py312h8908fee_0, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py311hf5cb60f_0, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py310hef7d0a5_0, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py39h1857587_0, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         ├─ opencv 4.10.0 would require
         │  └─ libopencv ==4.10.0 headless_py38he6231d4_0, which cannot be installed because there are no viable options:
         │     └─ libopencv 4.10.0 would require
         │        └─ ffmpeg >=6.1.1,<7.0a0, which cannot be installed because there are no viable options:
         └─ opencv 4.10.0 would require
            └─ libopencv ==4.10.0 headless_py39h7137bbe_0, which cannot be installed because there are no viable options:
               └─ libopencv 4.10.0 would require
                  └─ ffmpeg >=7.0.1,<8.0a0, which cannot be installed because there are no viable options:

It is possible to resolve this issue by changing the channel order to ["nvidia", "conda-forge", "pytorch"] and explicitly defining channel on the pytorch and pytorch-cuda dependency like this:
[project]
name = "pixi-cuda"
version = "0.1.0"
description = "Add a short description here"
authors = ["Tim-Oliver Buchholz"]
channels = ["nvidia", "conda-forge", "pytorch"]
platforms = ["linux-64"]

[feature.cuda.tasks]
check_cuda = 'python -c "import torch; print(torch.cuda.is_available())"'

[dependencies]
python = "3.11.*"
opencv = ">=4.10.0,<4.11"

[feature.cuda]
platforms = ["linux-64"]
system-requirements = {cuda = "11"}

[feature.cuda.dependencies]
pytorch-cuda = {version="11.8.*", channel="pytorch"}
pytorch-lightning = ">=2.3.0,<2.4"
pytorch = {version = ">=2.3.1,<2.4", channel="pytorch"}

[environments]
cuda = ["cuda"]

I think there is a more fundamental issue hiding here: If an installation fails due to the strict channel order, there might still be a way. I think that should be made more explicit in the failed solving. Either by automatically attempting an alternative channel order - maybe as a dry-run, and suggest the possible channel order (if any). Or maybe at the least suggest trying an alternative channel order if pixi.toml contains multiple channels?

I also came across this issue, like @roaldarbol stated the error message is non obvious that its a channel ordering issue. By moving pytorch to the bottom of the list of channel orderings I managed to get py-opencv installed, but this error message made me think there was some other incompatibility
default) pablo@pablo-ubuntu:~/0Dev/personal/sam2-dust3r$ pixi add py-opencv
 WARN Defined custom mapping channel https://conda.anaconda.org/pytorch/ is missing from project channels
ERROR error=repodata not found
  × failed to solve the conda requirements of 'default' 'linux-64'
  ╰─▶ Cannot solve the request because of: py-opencv * cannot be installed because there are no viable options:
      └─ py-opencv 4.2.0 | 4.2.0 | 4.5.0 | 4.5.0 | 4.5.0 would require
         └─ libopencv ==4.2.0 py36_5, for which no candidates were found.
      The following packages are incompatible
      ├─ rerun-sdk >=0.17.0,<0.18 can be installed with any of the following options:
      │  ├─ rerun-sdk 0.17.0 would require
      │  │  └─ python_abi 3.10.* *_cp310, which can be installed with any of the following options:
      │  │     └─ python_abi 3.10
      │  ├─ rerun-sdk 0.17.0 would require
      │  │  └─ python_abi 3.9.* *_cp39, which can be installed with any of the following options:
      │  │     └─ python_abi 3.9 | 3.9
      │  └─ rerun-sdk 0.17.0 would require
      │     └─ python_abi 3.8.* *_cp38, which can be installed with any of the following options:
      │        └─ python_abi 3.8
      ├─ py-opencv * can be installed with any of the following options:
      │  ├─ py-opencv 4.2.0 | 4.3.0 | 4.4.0 would require
      │  │  ├─ python_abi 3.6.* *_cp36m, which can be installed with any of the following options:
      │  │  │  └─ python_abi 3.6
      │  │  └─ python >=3.6,<3.7.0a0, which can be installed with any of the following options:
      │  │     └─ python 3.6.9 | 3.6.9 | 3.6.9 | 3.6.12 | 3.6.12
      │  ├─ py-opencv 4.2.0 | 4.3.0 | 4.4.0 would require
      │  │  ├─ python_abi ==3.6 *_pypy36_pp73, which can be installed with any of the following options:
      │  │  │  └─ python_abi 3.6 | 3.6
      │  │  └─ python >=3.6,<3.7.0a0, which can be installed with any of the following options:
      │  ├─ py-opencv 4.2.0 | 4.2.0 | 4.3.0 | 4.4.0 would require
      │  │  ├─ python_abi 3.8.* *_cp38, which can be installed with any of the following options:
      │  │  │  └─ python_abi 3.8
      │  │  └─ python >=3.8,<3.9.0a0, which can be installed with any of the following options:
      │  │     └─ python 3.8.12 | 3.8.13 | 3.8.16
      │  └─ py-opencv 4.2.0 | 4.2.0 | 4.3.0 | 4.4.0 would require
      │     ├─ python_abi 3.7.* *_cp37m, which can be installed with any of the following options:
      │     │  └─ python_abi 3.7 | 3.7 | 3.7
      │     └─ python >=3.7,<3.8.0a0, which can be installed with any of the following options:
      │        └─ python 3.7.9 | 3.7.9 | 3.7.10 | 3.7.10 | 3.7.12
      └─ python 3.11.* cannot be installed because there are no viable options:
         └─ python 3.11.0 | 3.11.0 | 3.11.0 | 3.11.0 | 3.11.1 | 3.11.2 | 3.11.3 | 3.11.4 | 3.11.5 | 3.11.6 | 3.11.7 | 3.11.7 | 3.11.8 | 3.11.9
      would constrain
            └─ python_abi 3.11.* *_cp311 , which conflicts with any installable versions previously reported

and all that was required was going from this
channels = [
    "https://prefix.dev/ai-demos",
    "nvidia",
    "nvidia/label/cuda-12.1.0",
    "pytorch",
    "conda-forge",
]

to this
channels = [
    "https://prefix.dev/ai-demos",
    "nvidia",
    "nvidia/label/cuda-12.1.0",
    "conda-forge",
    "pytorch",
]

The error message makes it difficult to tell exactly why its failing

another example I have is with the mmcv package, that installs perfectly fine if done through pypi but gives me a bunch of errors with conda-forge
(default) pablo@pablo-ubuntu:~/0Dev/personal/sam2-dust3r$ pixi add mmcv
 WARN Defined custom mapping channel https://conda.anaconda.org/pytorch/ is missing from project channels
ERROR error=repodata not found
  × failed to solve the conda requirements of 'default' 'linux-64'
  ╰─▶ Cannot solve the request because of: The following packages are incompatible
      ├─ pytorch ==2.3.1 can be installed with any of the following options:
      │  ├─ pytorch 2.3.1 | 2.3.1 | 2.3.1
      │  ├─ pytorch 2.3.1 | 2.3.1 would require
      │  │  └─ python >=3.9,<3.10.0a0, which can be installed with any of the following options:
      │  │     └─ python 3.9.10 | 3.9.12 | 3.9.16 | 3.9.17 | 3.9.18 | 3.9.18 would require
      │  │        └─ python_abi ==3.9 *_pypy39_pp73, which can be installed with any of the following options:
      │  │           └─ python_abi 3.9 | 3.9 | 3.9
      │  └─ pytorch 2.3.1 | 2.3.1 would require
      │     └─ python >=3.8,<3.9.0a0, which can be installed with any of the following options:
      │        └─ python 3.8.12 | 3.8.13 | 3.8.16 would require
      │           └─ python_abi ==3.8 *_pypy38_pp73, which can be installed with any of the following options:
      │              └─ python_abi 3.8 | 3.8 | 3.8
      ├─ pytorch-cuda 12.1.* can be installed with any of the following options:
      │  └─ pytorch-cuda 12.1 | 12.1 would require
      │     └─ libcublas >=<IP_ADDRESS>,<<IP_ADDRESS>, which can be installed with any of the following options:
      │        └─ libcublas <IP_ADDRESS>
      ├─ mmcv * cannot be installed because there are no viable options:
      │  ├─ mmcv 2.2.0 | 2.2.0 would require
      │  │  └─ libcublas >=<IP_ADDRESS>,<13.0a0, which cannot be installed because there are no viable options:
      │  │     ├─ libcublas <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> is excluded because due to strict channel priority not using this option from:
      'https://conda.anaconda.org/conda-forge/'
      │  │     └─ libcublas <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS>, which conflicts with the versions reported above.
      │  ├─ mmcv 2.2.0 would require
      │  │  └─ libcublas >=<IP_ADDRESS>,<13.0a0, which cannot be installed because there are no viable options:
      │  │     ├─ libcublas <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> is excluded because due to strict channel priority not using this option from:
      'https://conda.anaconda.org/conda-forge/'
      │  │     └─ libcublas <IP_ADDRESS>, which conflicts with the versions reported above.
      │  ├─ mmcv 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 would require
      │  │  └─ python_abi 3.12.* *_cp312, which cannot be installed because there are no viable options:
      │  │     └─ python_abi 3.12, which conflicts with the versions reported above.
      │  ├─ mmcv 2.1.0 would require
      │  │  └─ libcublas >=<IP_ADDRESS>,<13.0a0, which cannot be installed because there are no viable options:
      │  │     ├─ libcublas <IP_ADDRESS>, which conflicts with the versions reported above.
      │  │     ├─ libcublas <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> is excluded because due to strict channel priority not using
      this option from: 'https://conda.anaconda.org/conda-forge/'
      │  │     └─ libcublas <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS> | <IP_ADDRESS>, which conflicts with the versions
      reported above.
      │  ├─ mmcv 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0
      | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 would require
      │  │  └─ cudatoolkit >=11.8,<12, which cannot be installed because there are no viable options:
      │  │     └─ cudatoolkit 11.8.0 | 11.8.0 | 11.8.0 | 11.8.0 is excluded because due to strict channel priority not using this option from:
      'https://conda.anaconda.org/conda-forge/'
      │  ├─ mmcv 2.0.0 | 2.0.0 | 2.0.1 | 2.0.1 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.2.0 | 2.2.0 | 2.2.0 would
      constrain
      │  │  └─ pytorch * cpu* , which conflicts with any installable versions previously reported
      │  ├─ mmcv 2.0.0 | 2.0.0 | 2.0.0 | 2.0.0 | 2.0.1 | 2.0.1 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.2.0
      | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 would require
      │  │  └─ python_abi 3.10.* *_cp310, which cannot be installed because there are no viable options:
      │  │     ├─ python_abi 3.10 | 3.10, which conflicts with the versions reported above.
      │  │     └─ python_abi 3.10, which conflicts with the versions reported above.
      │  ├─ mmcv 2.0.0 | 2.0.0 | 2.0.0 | 2.0.0 | 2.0.1 | 2.0.1 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.2.0
      | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 would require
      │  │  └─ python_abi 3.9.* *_cp39, which cannot be installed because there are no viable options:
      │  │     ├─ python_abi 3.9 | 3.9, which conflicts with the versions reported above.
      │  │     ├─ python_abi 3.9, which conflicts with the versions reported above.
      │  │     └─ python_abi 3.9 would constrain
      │  │        └─ python_abi * *_cp39 , which conflicts with any installable versions previously reported
      │  └─ mmcv 2.0.0 | 2.0.0 | 2.0.0 | 2.0.0 | 2.0.1 | 2.0.1 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.1.0 | 2.2.0
      | 2.2.0 | 2.2.0 | 2.2.0 would require
      │     └─ python_abi 3.8.* *_cp38, which cannot be installed because there are no viable options:
      │        ├─ python_abi 3.8 | 3.8, which conflicts with the versions reported above.
      │        ├─ python_abi 3.8, which conflicts with the versions reported above.
      │        └─ python_abi 3.8 | 3.8 would constrain
      │           └─ python_abi * *_cp38 , which conflicts with any installable versions previously reported
      ├─ rerun-sdk >=0.17.0,<0.18 cannot be installed because there are no viable options:
      │  ├─ rerun-sdk 0.17.0 would require
      │  │  └─ python_abi 3.12.* *_cp312, which cannot be installed because there are no viable options:
      │  │     └─ python_abi 3.12, which conflicts with the versions reported above.
      │  ├─ rerun-sdk 0.17.0 | 0.17.0 would require
      │  │  └─ python_abi 3.11.* *_cp311, which cannot be installed because there are no viable options:
      │  │     ├─ python_abi 3.11 would constrain
      │  │     │  └─ python 3.11.* *_cpython , which conflicts with any installable versions previously reported
      │  │     ├─ python_abi 3.11 | 3.11, which conflicts with the versions reported above.
      │  │     └─ python_abi 3.11, which conflicts with the versions reported above.
      │  ├─ rerun-sdk 0.17.0 would require
      │  │  └─ python_abi 3.10.* *_cp310, which cannot be installed because there are no viable options:
      │  │     └─ python_abi 3.10, which conflicts with the versions reported above.
      │  ├─ rerun-sdk 0.17.0 would require
      │  │  └─ python_abi 3.9.* *_cp39, which cannot be installed because there are no viable options:
      │  │     ├─ python_abi 3.9, which conflicts with the versions reported above.
      │  │     └─ python_abi 3.9 would constrain
      │  │        └─ python_abi * *_cp39 , which conflicts with any installable versions previously reported
      │  └─ rerun-sdk 0.17.0 would require
      │     └─ python_abi 3.8.* *_cp38, which cannot be installed because there are no viable options:
      │        ├─ python_abi 3.8, which conflicts with the versions reported above.
      └─ python 3.11.* cannot be installed because there are no viable options:
         └─ python 3.11.0 | 3.11.0 | 3.11.0 | 3.11.0 | 3.11.1 | 3.11.2 | 3.11.3 | 3.11.4 | 3.11.5 | 3.11.6 | 3.11.7 | 3.11.7 | 3.11.8 | 3.11.9
      | 3.11.9 would constrain
            └─ python_abi 3.11.* *_cp311 , which conflicts with any installable versions previously reported

https://prefix.dev/channels/conda-forge/packages/mmcv
for this pixi.toml
[project]
authors = [{ name = "pablovela5620", email =<EMAIL_ADDRESS>}]
dependencies = []
description = "Add a short description here"
name = "sam2-dust3r"
requires-python = ">= 3.11"
version = "0.1.0"

[build-system]
build-backend = "hatchling.build"
requires = ["hatchling"]

[tool.pixi.project]
channels = [
    "https://prefix.dev/ai-demos",
    "nvidia",
    "nvidia/label/cuda-12.1.0",
    "conda-forge",
    "pytorch",
]
conda-pypi-map = { "pytorch" = "torch_mapping.json" }
platforms = ["linux-64"]

[tool.pixi.system-requirements]
cuda = "12"
libc = { family = "glibc", version = "2.31" }

[tool.pixi.pypi-dependencies]
sam-2 = { git = "https://github.com/facebookresearch/segment-anything-2.git", rev = "0db838b11726893f151fa5826ecfa744e1a7760f", extras = [
    "demo",
] }
sam2-dust3r = { path = ".", editable = true }

[tool.pixi.dependencies]
python = "3.11.*"
pytorch = { version = "2.3.1", channel = "pytorch" }
torchvision = { version = "0.18.1", channel = "pytorch" }
cuda = { version = "*", channel = "nvidia/label/cuda-12.1.0" }
pytorch-cuda = { version = "12.1.*", channel = "pytorch" }
huggingface_hub = ">=0.24.5,<0.25"
rerun-sdk = ">=0.17.0,<0.18"
simplecv = { version = ">=0.0.2,<0.0.3", channel = "https://prefix.dev/ai-demos" }

[tool.pixi.tasks]

Hi all, this is a unfortunately still hard. I discussed it in this discussion: https://github.com/prefix-dev/pixi/discussions/1812
TL;DR: try if it solves with channel-priority = "disabled" in the [project] table. If that works please turn it back of and setup your dependencies to come from the right channel as was solved by pixi.

[!WARNING]
channel-priority = "disabled" can be very dangerous as there is no guarantee that the same package is getting installed from the same channel every time. This is a possible security risk as someone can name drop to overwrite a package with something you didn't expect.

The original issue from @slobodaapl is something that will not work. pixi global can only install tools at the moment of writing this. So not libraries like you requested. Making a project should work for this e.g.:
[project]
channels = ["conda-forge", "pytorch"]
name = "pytorch"
platforms = ["linux-64"]

[dependencies]
pytorch = ">=2.3.1,<3"
torchvision = ">=0.18.0,<0.20"
torchaudio = ">=2.3.1,<3"

# Important to tell pixi that `cuda` is available and which version it can expect on all machines the project needs to run on.
[system-requirements]
cuda = "12.1"

[tasks]
cuda-available = "python -c 'import torch; print(torch.cuda.is_available())'"
---

Thank you for the context, this is helpful. One last question I have is, once I've turned off channel-priority channel-priority = "disabled" and I have things working. Is the idea that I would basically look for the packages I have defined and then specify each channel for each package? I think that's where I'm still a bit confused.
Also there's some confusion on my end for the system-requirements. Does setting cuda ="12.1" mean exactly that version of cuda, or 12.1 and above? Lastly does getting cuda from the nvidia channel like this also satisfy the requirement?
cuda = { version = "*", channel = "nvidia/label/cuda-12.1.0" }

Hi @pablovela5620,
Disabling channel-priority can really easily result in future breaking setups when you for instance run pixi update as these channels can "do what they want". So best practice would be to check if it "can" work with the priority disabled but then use that result to manually set it up in your toml to make sure it would not break in the future.
TL;DR: System-requirements define minimal requirements.
In theory it's the description of the machine you solve for. This means you tell pixi. Solve as if you're running on a machine with cuda = "12.1" but because (i believe) all virtual package dependencies are written as cuda >= 12.1 this would result in the minimal requirement.
The cuda dependencies from the labeled channel will indeed get you cuda-12.1.0 because it can only fetch from this channel: https://anaconda.org/nvidia/cuda/files?channel=cuda-12.1.0.

No idea if this helps, but an FYI, the solution posted here doesn't seem to work for me and I still end up with a cpu pytorch :
[project]
channels = ["conda-forge", "pytorch"]
platforms = ["linux-64"]
name = "test"

[system-requirements]
cuda = "12.3"

[dependencies]
pytorch = ">=2.3.1,<3"
python = "3.10.*"

and
pixi list | grep pytorch
pytorch            2.4.0       cpu_generic_py310h6ad04bf_1  30.6 MiB   conda  pytorch-2.4.0-cpu_generic_py310h6ad04bf_1.conda

This should be fixed once https://github.com/prefix-dev/pixi/pull/2025 is merged.
TDLR:
With that change, the solver will always prioritize maximizing the versions of explicit requirements over transitive dependencies.
Explanation:
The problem with the reproducer from @timlacroix is that the solver first decides on a version for python and then decides on an openmp version required by Python. It will decide on libgomp, which is incompatible with pytorch CUDA. So once the solver tries to decide on pytorch, the CUDA version is no longer selectable.
With the changes to the solver, the solver will not first decide on the transitive dependency for openmp but it will first decide on a version of pytorch instead. This will then select the best available pytorch version which is the CUDA version. Only then will it decide on a compatible openmp version.
Before the above PR:
> pixi list | grep pytorch
pytorch            2.4.0       cpu_generic_py310h6ad04bf_1  30.6 MiB   conda  pytorch-2.4.0-cpu_generic_py310h6ad04bf_1.conda

With the above PR:
> pixi list | grep pytorch
pytorch               2.4.0       cuda120_py310h2c91c31_301  30.6 MiB   conda  pytorch-2.4.0-cuda120_py310h2c91c31_301.conda

Are you also saying that maybe another version of libgomp should be prioritized?

Are you also saying that maybe another version of libgomp should be prioritized?

Im not entirely sure which one should be prioritized over others. But I think it being a transitive dependency should not restrict the version we select for a direct dependency.

Okay!
With #2025 now merged this yields:
[project]
authors = ["Tim de Jager<EMAIL_ADDRESS>channels = ["conda-forge"]
description = "Add a short description here"
name = "torch"
platforms = ["linux-64"]
version = "0.1.0"

[tasks]

[system-requirements]
cuda = "12.3"

[dependencies]
pytorch = "*"

$ pixi list --platform linux-64 | grep pytorch

pytorch               2.4.0       cuda120_py312h26b3cf7_301  24.6 MiB   conda  pytorch-2.4.0-cuda120_py312h26b3cf7_301.conda

Will this transparently also translate to a pixi global install?.. Or rather, are either of these possible:
a) Specify all packages in pixi toml to be installed as global
b) Use the pixi global install command from CLI with specifying the cuda as system requirement
c) Any other mechanism to globally install torch with cuda using pixi
Thank you

@slobodaapl We're not planning to support global installation of libraries like torch. pixi global creates a virtual environment per "tool" and if you do this for libraries you can easily get conflicting libraries between the different virtual environments.
A) The next version of pixi global will contain the ability to create some more interesting virtual environments that can be activated globally.
B) The pixi global install doesn't need system-requirements as it uses the once from your own system directly, not the default set we define for the projects. This is because you don't need to be able to share the global installation.
C) torch as a library no, but an environment that contains torch and other tools that depend on it would be possible with the next version (answer A).

@ruben-arts
That's a valid point, I don't know the mechanics behind pixi enough, I had a misunderstanding of what the global install does.
What I'm looking to do, which is something that even Poetry lacks right now without workarounds, is to install global site packages to use as a "base" environment, and which are considered "concrete".
The goal is to develop a development environment with some predetermined fixed requirements that should be inherited and not touched, with the specific versions they're at, and then create virtual environments in projects that inherit the global packages, without pointlessly re-downloading different versions of them and reinstalling them in the .venv
Is there currently any reasonable way to achieve this?

The main purpose of pixi is to help avoid workflows like this 😅. Same applies to tools like uv, poetry, and others in ecosystems like cargo, npm, etc.
That said, it’s doable. The most flexible approach is to create a pixi project and activate it within your shell’s initialization.

Create a pixi project:
pixi init global-env
cd global-env
# Add your system requirements manually
pixi add pytorch  # Add any other tools/packages needed

Add this line to your shell’s rc file (e.g. .bashrc):
eval "$(pixi shell-hook --manifest-path /path/to/global-env/pixi.toml)"

Reload your terminal.

[!IMPORTANT]
After setting this up, all pixi commands will be tied to that project, essentially disabling other workflows.

[!WARNING]
If you use pip install after enabling the shell hook, it will install into the pixi project, which will break things.

P.S. If this approach seems too cumbersome, I’ve proposed another idea that leverages caching, which could solve your issue differently. Check out the discussion here: https://github.com/prefix-dev/pixi/discussions/1354.

The main purpose of pixi is to help avoid workflows like this 😅. Same applies to tools like uv, poetry, and others in ecosystems like cargo, npm, etc.
That said, it’s doable. The most flexible approach is to create a pixi project and activate it within your shell’s initialization.

Create a pixi project:pixi init global-env
cd global-env
# Add your system requirements manually
pixi add pytorch  # Add any other tools/packages needed

Add this line to your shell’s rc file (e.g. .bashrc):eval "$(pixi shell-hook --manifest-path /path/to/global-env/pixi.toml)"

Reload your terminal.

Important
After setting this up, all pixi commands will be tied to that project, essentially disabling other workflows.
Warning
If you use pip install after enabling the shell hook, it will install into the pixi project, which will break things.
P.S. If this approach seems too cumbersome, I’ve proposed another idea that leverages caching, which could solve your issue differently. Check out the discussion here: #1354.

Hmm is it the point to avoid those workflows though?.. Conda by default uses hardlinks when cloning a 'base' environment to avoid taking up more space and using up more disk, or to avoid taking a long time to set up.
The neat thing about Poetry, Pixi, etc., is the streamlined TOML files which allow a lot of flexibility and configuration in one place, plus various other benefits.. but it seems to actually lack that ability, in both cases.
However the cache approach you mention on #1354 does actually seem like a very reasonable approach that gives us best of both worlds, saving on disk space, setup times, but also avoiding potentially breaking combination of versions.
At any rate, #2025 fixes the issue of installing pytorch, so I'll close this issue.

Conda by default uses hardlinks when cloning a 'base' environment to avoid taking up more space and using up more disk, or to avoid taking a long time to set up.

pixi does the linking too, even uses a reflink when possible which makes it safe too. But it doesn't reuse the cache yet.

Hmm is it the point to avoid those workflows though?

I believe that your goal is not to install globally but just to avoid the double download.
The workflow I proposed can easily take up more time in debugging and fixing problems when you accidentally do a pip install for instance. To avoid that most modern tools work with dedicated file-system based virtual environments. To avoid mixing all projects and their environments, also known as the kitchen sink.


Add support for passing custom references

Enables passing raw references in the release configuration parameter. This allows the user to build  preview rendering of the site using the Prismic.io dashboard preview button.
Suggested solution for #24

Thanks @aeirola for the enhancement and test! Give me a day or so to package it up and release.


Dead Zone

There's some dead zone on main screen, the view won't scroll from there, that's lower middle part.

I had that issue in one of the builds, then it disappeared


Wools dont re-appear in chests

This problem is kind of the same, but the difference is that this issue is with phisical blocks instead of inventory blocks
#434

@AngelCasillas01 ok, agrega esta issue a la #434 y cierro esta

This is a different feature

@TiTo-418 no dejala abiera para saber cuando lo resuelvan xaval

Auto-refill chest is only able on Public OCN. In tourneys it's disabled to prevent safety spam. I don't think that this should be added

@Alfalik If you take all the wools?

@TiTi-418 Yes. If you pick up all the wools in the chest, you easily can spam safeties when bringing it back, wich make an easier job for your team. Disabling auto-refill prevent it.

If you take all the wools, and lose it, you can't win the match

@TiTi-418 The chest have 54 wools, I don't see why do you need to pick up all. Auto-refill is a new feature that hasn't been used in old tourneys, and actually isn't used.

If i arrive to the wool room 55 times, i can't get one. If i arrive 6 times to the wool room and i pick up 14 wools, i can't get one etc,etc

Tourney maps are made to be strategic. What would be the point of coming to a wool room, take all the wools, block spam it and if you die, go back to the wool room and repeat?
If it's disabled in the Tourney Plugin or module of PGM, it should be disabled / not added in Cardinal.

Maybe a toggeable option?

What I am currently working with is a configurable rate (mostly because I don't know the actual rate). By default it will be set to 0, so disabled.

This can be a module and be toggleable in the map xml

@titi-418 Then if you want to get 55 times and get 55 times out of the wool and die try to organize better before going out. Also auto refill haven't been used in any Overcast Network tournament so far so at this point is not needed.

This is only used for public, in TM and in Tournaments it's disabled completly, should this really be an issue?

Yes, because this is a feature that should some day be implemented.


get_ranked_stats  from cassiopeia/cassiopeia/core/statsapi.py

https://github.com/robrua/cassiopeia/blob/789e354bbcd1e091c50c8c562adfc64ff69d5133/cassiopeia/core/statsapi.py
I get that this function will return
{object of champ: object of my aggstat of that champ}
For example,
dyrus = riotapi.get_summoner_by_name("dyrus")
dyrusstat=riotapi.get_ranked_stats(summoner=dyrus, season=Season.season_5)
Now, if I print(dyrusstat[object of champ]), I will get the agg stat of that object of champ.
But I am not able to understand how to bring that object of champ.
if I want to call how dyrus did for "Dr. Mundo". How can I index within this dictionary generated by the function?
I tried to bring a champ object by using cassiopeia.riotapi.get_champions_by_id() function, but didnt work. (i.e dyrusstat[cassiopeia.riotapi.get_champions_by_id(36)] where 36 is mundo id > this didn't work)

You'll want to use either riotapi.get_champion_by_id(36) or riotapi.get_champion_by_name("Dr. Mundo") to get the champion object for Mundo.


GDExtension: Copy DLL to a temp file before opening

This is done only in the editor and only on Windows, to avoid a file lock that prevents the original library being updated (e.g. by a compiler).
When the game runs it will load the original DLL and pick up any changes, only the editor will stay with the copy (until it is restarted and create a new copy).
The copy is done in place by prepending a ~ to the original file name, so dependencies that are loaded with a relative file path still work. When the library is unloaded the copy file is deleted.
Closes https://github.com/godotengine/godot-cpp/issues/955
Note: This still does not enable actual reloading for GDExtension, but it is a step towards it.

Updated to remove the define.

Needs rebase to fix a temporary extension compat error.

Very very nice, fantastic job! 💖
I manually rebased this onto f2acfb1ffc94d0e381064070108e7a773d86177d and tried it with godot-rust.
Only tested simple examples so far, but it seems to work as expected! 👍

Updated to set the temp file as hidden. I didn't set the read attribute because I think it's not relevant (the file can't be written anyway because of the open lock). Given the name it's also set as an "protected OS file" so it does not show unless you have the option on to show these types of files, which is an extra bonus.

Discussed at the GDExtension, and we think this looks awesome!

I retested this with the latest changes, and I noticed a minor issue: if the .dll exists but fails to load for any reason, the copy won't get cleaned up when the editor closes. Probably this should delete the copy right away if there's an error opening the library.

I retested this with the latest changes, and I noticed a minor issue: if the .dll exists but fails to load for any reason, the copy won't get cleaned up when the editor closes. Probably this should delete the copy right away if there's an error opening the library.

It probably just requires adding some cleanup code on each possible early return/fail condition in the loading function.
Can be done as a follow-up, let's merge the current version for wider testing.

Can be done as a follow-up, let's merge the current version for wider testing.

Sounds good! I can make the follow up :-)

Thanks!


Route refresh is ignored

Apologies beforehand for posting this here rather than the OpenBSD bugs list.
I have observed that route refresh messages are discarded unexpectedly by OpenBGPD, at least in my tests with a neighbor which does not support RFC7313 (enhanced route refresh capability). route refresh: AID IPv4 unicast not negotiated is logged and apparently points to a regression introduced in rde.c revision 1.548. Also considering the description therein, the issue is indeed fixed with the following one-line change:
--- a/src/bgpd/rde.c	2022-10-03 18:20:06.000000000 +0300
+++ b/src/bgpd/rde.c	2023-01-12 19:59:10.540874769 +0200
@@ -1122,7 +1122,7 @@
 			    "route refresh: bad AID %d", rr.aid);
 			break;
 		}
-		if (peer->capa.mp[rr.aid]) {
+		if (peer->capa.mp[rr.aid] == 0) {
 			log_peer_warnx(&peer->conf,
 			    "route refresh: AID %s not negotiated",
 			    aid2str(rr.aid));

Fixed in rev. 1.586 of rde.c, thanks for the report.


#18 Created script that register aux services

Codecov Report

Merging #19 (d70c9c3) into master (39fbc80) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #19   +/-   ##
=======================================
  Coverage   61.90%   61.90%
=======================================
  Files          42       42
  Lines         525      525
  Branches       16       16
=======================================
  Hits          325      325
  Misses        200      200

Continue to review full report at Codecov.

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


case class default field values

It would be useful to support default field values when decoding.
case class Entity(id: Long, description: String = "")

"""{"id":42}""".fromJson[Entity] == Right(Entity(42L, ""))

I can provide a PR if needed.

I can provide a PR if needed.
Go for it!

what release is this in? I'm exactly needing this desperately :)

Only in snapshot releases so far. The Readme in GitHub has a link to the latest snapshot

@fsvehla thx! (though i'm not finding any way to successfully add the snapshots resolver to my project atm :( )

the error i'm seeing (likely my fault) is
[error]   not found: https://repo1.maven.org/maven2/dev/zio/zio-json_2.12/0.1+17-974132cc-SNAPSHOT/zio-json_2.12-0.1+17-974132cc-SNAPSHOT.pom

derp, i was missing a resolver in one sub build. i'll try it agian :)


RLC-410 truncates password at 31 characters

Describe the bug
Reolink cameras truncate passwords at 31 characters silently - and they do it in the login page, so if you pass the full 32-character password that you set in the camera's settings to this amazing integration, it will fail. This far from a security best practice, but I think the HA integration should probably behave the same as the camera's own login page.
To Reproduce

Create an account on your reolink camera, with a 32 character password.
Log in to the account via webUI, observe that it works
Use the same password to set up the reolink integration in HomeAssistant.

I figured out that they were truncating by going to the camera's login page, opening the network tab of chrome developer tools, and seeing that the password that actually gets sent out in the login request is truncated to 31 characters. Specifying the 31-character truncated version of the password when setting up the HA integration works. I think you just need a [:31] when sending out the password.
Expected behavior
Camera should be added successfully. In reality, we get an error.
Environment:

Home Assistant version: HassOS 4.17, 2020.12.6
Reolink camera model: RLC-410-5MP
Camera firmware number:

Build No. build 20121100
Hardware No. IPC_51516M5M
Config Version v<IP_ADDRESS>
Firmware Version v<IP_ADDRESS>_20121100

Additional context
2020-12-15 21:13:17 DEBUG (MainThread) [custom_components.reolink_dev.base] {'port': 80, 'host': '<IP_ADDRESS>', 'username': 'REDACTED', 'password': '32 character password goes here!'}
2020-12-15 21:13:17 DEBUG (MainThread) [custom_components.reolink_dev.base] []
2020-12-15 21:13:17 DEBUG (MainThread) [reolink.camera_api] Reolink camera with host <IP_ADDRESS>:80 trying to login with user REDACTED
2020-12-15 21:13:18 DEBUG (MainThread) [reolink.camera_api] Get response from <IP_ADDRESS>: [{'cmd': 'Login', 'code': 1, 'error': {'detail': 'param error', 'rspCode': -4}}]
2020-12-15 21:13:18 ERROR (MainThread) [reolink.camera_api] Failed to login at IP x.x.x.x. Connection error.
2020-12-15 21:13:18 ERROR (MainThread) [reolink.camera_api] Error translating Reolink settings response

Thanks! It's clear to me and I will add it to the next release.

Can you check if it works with the latest version? Perhaps it should also be added to the motion event subscription. Let me know!

Yes, tested the new version and it works. Thanks!
fwestenberg/reolink@7089c45677ccfbde26309a682215e9f7903c1c7e

Yes, tested the new version and it works. Thanks!
fwestenberg/reolink@7089c45

Motion detection also working?

Motion detection does not appear to be working, shows as "Unavailable" in Lovelace. I see
2020-12-26 22:55:47 ERROR (MainThread) [custom_components.reolink_dev.base] Host <IP_ADDRESS> error renewing the Reolink subscription
2020-12-26 22:55:47 DEBUG (MainThread) [reolink.subscription_manager] Reolink host <IP_ADDRESS> got response status: 400. Payload: {<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsdd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsa5="http://www.w3.org/2005/08/addressing" xmlns:xmime="http://tempuri.org/xmime.xsd" xmlns:xmime5="http://www.w3.org/2005/05/xmlmime" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:wsrfbf="http://docs.oasis-open.org/wsrf/bf-2" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:wsrfr="http://docs.oasis-open.org/wsrf/r-2" xmlns:ns1="http://www.onvif.org/ver10/actionengine/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:ns10="http://www.onvif.org/ver10/events/wsdl/PullPointBinding" xmlns:ns11="http://www.onvif.org/ver10/events/wsdl/CreatePullPointBinding" xmlns:ns12="http://www.onvif.org/ver10/events/wsdl/PausableSubscriptionManagerBinding" xmlns:ns13="http://www.onvif.org/ver10/network/wsdl/RemoteDiscoveryBinding" xmlns:ns14="http://www.onvif.org/ver10/network/wsdl/DiscoveryLookupBinding" xmlns:tdn="http://www.onvif.org/ver10/network/wsdl" xmlns:ns3="http://www.onvif.org/ver20/analytics/wsdl/RuleEngineBinding" xmlns:ns4="http://www.onvif.org/ver20/analytics/wsdl/AnalyticsEngineBinding" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:ns5="http://www.onvif.org/ver10/events/wsdl/PullPointSubscriptionBinding" xmlns:ns6="http://www.onvif.org/ver10/events/wsdl/EventBinding" xmlns:ns7="http://www.onvif.org/ver10/events/wsdl/SubscriptionManagerBinding" xmlns:ns8="http://www.onvif.org/ver10/events/wsdl/NotificationProducerBinding" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:ns9="http://www.onvif.org/ver10/events/wsdl/NotificationConsumerBinding" xmlns:tad="http://www.onvif.org/ver10/analyticsdevice/wsdl" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tls="http://www.onvif.org/ver10/display/wsdl" xmlns:tmd="http://www.onvif.org/ver10/deviceIO/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:trc="http://www.onvif.org/ver10/recording/wsdl" xmlns:trp="http://www.onvif.org/ver10/replay/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:trv="http://www.onvif.org/ver10/receiver/wsdl" xmlns:tse="http://www.onvif.org/ver10/search/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><SOAP-ENV:Header></SOAP-ENV:Header><SOAP-ENV:Body><SOAP-ENV:Fault SOAP-ENV:encodingStyle="http://www.w3.org/2003/05/soap-encoding"><SOAP-ENV:Code><SOAP-ENV:Value>SOAP-ENV:Sender</SOAP-ENV:Value><SOAP-ENV:Subcode><SOAP-ENV:Value>ter:NotAuthorized</SOAP-ENV:Value></SOAP-ENV:Subcode></SOAP-ENV:Code><SOAP-ENV:Reason><SOAP-ENV:Text xml:lang="en">Sender not Authorized</SOAP-ENV:Text></SOAP-ENV:Reason></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
}
2020-12-26 22:55:47 DEBUG (MainThread) [custom_components.reolink_dev] Finished fetching reolink data in 0.588 seconds```

In logs.

I also encountered

Logger: homeassistant.config_entries
Source: custom_components/reolink_dev/init.py:176
First occurred: 10:53:20 PM (1 occurrences)
Last logged: 10:53:20 PM
Error unloading entry Camera1 for reolink_dev
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 321, in async_unload
result = await component.async_unload_entry(hass, self)  # type: ignore
File "/config/custom_components/reolink_dev/init.py", line 184, in async_unload_entry
await unregister_webhook(hass, base.event_id)
File "/config/custom_components/reolink_dev/init.py", line 176, in unregister_webhook
_LOGGER.info("Unregistering webhook %s", info.name)
AttributeError: 'dict' object has no attribute 'name'

when adding/removing the integration to test.

This should be fixed in v0.12. Please reopen if not.

This should be fixed in v0.12. Please reopen if not.


Delete Table not working

Go: 1.21.1
Excelize: master
Updating a table's range by removing it and creating it again doesn't work.
func main() {
	f, err := excelize.OpenFile("template.xlsx")
	if err != nil {
		panic(err)
	}

	err = f.SetSheetRow("Data", "A7", &[]any{"2023-10-06", 140})
	if err != nil {
		panic(err)
	}
	err = f.DeleteTable("Table1")
	if err != nil {
		panic(err)
	}
	err = f.AddTable("Data", &excelize.Table{
		Name:  "Table1",
		Range: "A1:B7",
	})
	if err != nil {
		panic(err)
	}
	err = f.SaveAs("output.xlsx")
	if err != nil {
		panic(err)
	}

}

//panic: the same name table already exists

Excelize.zip
Also Is there a way to refresh the range of a chart ? or make the chart react to a table new row ?

Thanks for your issue. This issue has been fixed, please try to upgrade the master branch code, and this patch will be released in the next version. This library does not support change the data range of the chart currently, but you can delete the chart and create a new chart instead of that.

@xuri I can confirm the issue is fixed. However DeleteTable deletes the table header ? is this the intended behavior ?
Also Add table doesn't specify a way to specify a header for the table.
If i have the header as
Date, Values
2023-10-05, 10

// After Delete Header
2023-10-05, 10

// After AddTable
Column1, Column2
2023-10-05, 10

is there a way to do this without losing the table header ?

Yes, I think we need to keep all cells value in the table range when deleting table, these section code is not required, would you like to create a pull request for that?

Yes I will by the end of today.


Wiped Lovelace overview page

HA Client version:
1.20(42)
Home Assistant version:
0.102.3
Device name:
Samsung Galaxy S9
Android version:
9
Description
First time using this app and I added the device tracker badge for the mobile app to my Lovelace overview page but now the page is blank 😔 other tabs are unaffected.
Help.

So I tried to add a badge with device_tracker and it works fine for me:

Could you please attach your Lovelace UI config here? You can find it tapping three-dots menu in upper right corner of web UI, selecting "Configure UI" then tapping the same three-dots menu again and selecting "Raw config editor". It will realyy help in solving this issue. Thanks.

I forgot about that option! I thought I'd have to wait till I was home to
edit the file directly. Unfortunately on my phone I can't copy all but I
found the offending line under badges:
  - entity: {}

Or was it
- {}
I copied before I deleted it but it copied something else, I'm guessing on
Android the copy in the raw config editor is a bit buggy.
On Mon, 16 Dec 2019, 17:05 Yegor Vialov<EMAIL_ADDRESS>wrote:

So I tried to add a badge with device_tracker and it works fine for me:
[image: Screenshot_20191216-190140]
https://user-images.githubusercontent.com/1819786/70926975-c265dd80-2036-11ea-9d4e-d3be31d27d56.png
Could you please attach your Lovelace UI config here? You can find it
tapping three-dots menu in upper right corner of web UI, selecting
"Configure UI" then tapping the same three-dots menu again and selecting
"Raw config editor". It will realyy help in solving this issue. Thanks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/estevez-dev/ha_client/issues/518?email_source=notifications&email_token=ABMVGG5BIDDN5XL3M6WBYALQY6YO7A5CNFSM4J3J2E22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG7MRMY#issuecomment-566151347,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMVGGZTMBQ7IY5ORJBEWELQY6YO7ANCNFSM4J3J2E2Q
.

So removing those line resolved the issue or not?

Yep. I'll try adding another badge see if happens again in a bit.
On Mon, 16 Dec 2019, 17:48 Yegor Vialov<EMAIL_ADDRESS>wrote:

So removing those line resolved the issue or not?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/estevez-dev/ha_client/issues/518?email_source=notifications&email_token=ABMVGG4MRKHON5XLVPHD6YTQY65PBA5CNFSM4J3J2E22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG7QUWA#issuecomment-566168152,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMVGG7EW5CGST2RQHRLSRTQY65PBANCNFSM4J3J2E2Q
.

So I tried adding it again and again it added - {}. I also noticed adding a new entity on my lights panel didn't work so I don't think this is badge specific.
`title: Home
views:

badges:

entity: device_tracker.google_maps_
entity: sensor.disk_use_percent_home
entity: sensor.memory_free
entity: sensor.time_online
entity: sensor.cpu_temperature
entity: device_tracker.mobile
cards:
entities:

light.fireplace_light
light.living_room_light
light.kitchen_light
title: Lights
type: entities

entities:

entity: switch.tv
entity: switch.hi_fi
entity: switch.meye01
entity: switch.ender3
entity: switch.sonoff_washing
title: Plugs
type: entities

entity: light.kitchen_light
type: light
entity: light.living_room_light
type: light
entity: light.fireplace_light
type: light
entity: light.living_room_bookshelf_led_strip
type: light
entity: light.hyperion
type: light
cards:

entity: script.light_colour_cycle1
hold_action:
action: none
icon: 'mdi:lighthouse-on'
icon_height: 50px
name: Colour Cycle Lights
show_icon: true
show_name: true
tap_action:
action: toggle
type: entity-button
entity: script.light_colour_cancel
hold_action:
action: none
icon: 'mdi:lightbulb-on-outline'
icon_height: 50px
name: Reset Lights to White
show_icon: true
show_name: true
tap_action:
action: toggle
type: entity-button
type: horizontal-stack

entities:

entity: scene.chill
entity: scene.party_mode
entity: scene.play_some_music
entity: scene.play_a_movie
entity: scene.watch_tv
show_header_toggle: false
title: Scenes
type: entities

entity: script.docker_restart_hass
hold_action:
action: more-info
icon: 'mdi:content-duplicate'
icon_height: 50px
show_icon: true
show_name: true
tap_action:
action: toggle
type: entity-button
card:
entity: media_player.kodi_he
type: media-control
conditions:

entity: media_player.kodi_he
state: playing
type: conditional

card:
entity: media_player.kodi_pi
type: media-control
conditions:

entity: media_player.kodi_pi
state: playing
type: conditional

card:
entity: media_player.chromecast_audio_hi_fi
type: media-control
conditions:

entity: media_player.chromecast_audio_hi_fi
state: playing
type: conditional

card:
entity: media_player.chromecast_main_tv
type: media-control
conditions:

entity: media_player.chromecast_main_tv
state: playing
type: conditional

card:
entity: media_player.google_home_living_room_speaker
type: media-control
conditions:

entity: media_player.google_home_living_room_speaker
state: playing
type: conditional

entities:

entity: automation.home_alarm
icon: 'mdi:alarm-light'
name: Home Alarm Armed
entity: automation.home_presence
icon: 'mdi:lightbulb-on'
name: Switch on lights when home
entity: automation.home_non_presence
icon: 'mdi:lightbulb-outline'
name: Switch off lights when away
entity: binary_sensor.front_door_occupancy
show_header_toggle: false
title: Visitor Presence
type: entities

detail: 2
entity: sensor.front_door_temperature
graph: line
hours_to_show: 24
type: sensor
entities:

entity: media_player.chromecast_audio_hi_fi
icon: 'mdi:google-chrome'
entity: media_player.google_home_living_room_speaker
icon: 'mdi:google-assistant'
entity: media_player.chromecast_main_tv
icon: 'mdi:google-chrome'
entity: media_player.kodi_pi
icon: 'mdi:kodi'
entity: media_player.kodi_he
icon: 'mdi:kodi'
show_header_toggle: false
theme: Backend-selected
title: Media Players
type: entities

entities:

input_boolean.weekend_sunrise
sensor.weekend_alarm_time
input_number.weekend_alarm_hour
input_number.weekend_alarm_minutes
type: entities

entities:

input_boolean.weekday_sunrise
sensor.weekday_alarm_time
input_number.weekday_alarm_hour
input_number.weekday_alarm_minutes
type: entities

entities:

entity: sensor.sonoff_washing_energy_power
hours_to_show: 1
title: Washing Machine Power Usage
type: history-graph

entities:

entity: input_select.state_washingmachine
hours_to_show: 2
title: Washing Machine History
type: history-graph

entities:

entity: input_select.state_washingmachine
entity: sensor.sonoff_washing_energy_current
icon: 'mdi:power-socket'
name: Actual Current Usage
entity: sensor.sonoff_washing_energy_power
icon: 'mdi:power-socket'
name: Actual Power Usage
entity: sensor.sonoff_washing_energy_today
icon: 'mdi:power-socket'
name: Energy Used Today
entity: sensor.sonoff_washing_energy_yesterday
icon: 'mdi:power-socket'
name: Energy Used Yesterday
entity: sensor.sonoff_washing_energy_total
icon: 'mdi:power-socket'
name: Total Energy
entity: sensor.sonoff_washing_energy_totalstarttime
icon: 'mdi:calendar'
name: Total Energy Reset Date
show_header_toggle: false
title: Washing Machine
type: entities

entity: light.led_djbox
type: light
path: default_view
title: Overview

badges: []
cards:

card:
entity: camera.mjpeg_camera
type: picture-entity
conditions:

entity: switch.meye01
state: 'on'
type: conditional
title: Living Room

badges: []
cards: []
title: Bedroom-Main
badges: []
cards: []
title: Kitchen
badges: []
cards:

entities:

entity: media_player.chromecast_audio_hi_fi
icon: 'mdi:google-chrome'
entity: media_player.google_home_living_room_speaker
icon: 'mdi:google-assistant'
entity: media_player.chromecast_main_tv
icon: 'mdi:google-chrome'
entity: media_player.kodi_pi
icon: 'mdi:kodi'
entity: media_player.kodi_he
icon: 'mdi:kodi'
show_header_toggle: false
theme: Backend-selected
title: Media Players
type: entities
title: Entertainment

badges: []
cards:

entities:

entity: sensor.front_door_temperature
entity: sensor.sensornode2_bme680_temperature
hours_to_show: 72
title: Home Temperature
type: history-graph

entities:

sensor.sensornode2_bme680_humidity
type: history-graph

entities:

entity: sensor.sensornode2_bme680_gas
type: history-graph

entities:

entity: sensor.sensornode2_bme680_pressure
type: history-graph

entities:

entity: sensor.sensornode2_bh1750_illuminance
type: history-graph
title: Climate

badges: []
cards: []
title: Security
badges: []
cards:

entities:

entity: sensor.processor_use
title: System CPU Usage
type: history-graph

entities:

entity: sensor.cpu_temperature
hours_to_show: 1
title: System CPU Temperature
type: history-graph

entities:

entity: sensor.memory_free
title: System Free Memory
type: history-graph

entities:

entity: sensor.network_throughput_in_eth0
title: System Download Rate
type: history-graph

entities:

entity: sensor.network_throughput_out_eth0
title: System Upload Rate
type: history-graph

entities:

entity: switch.docker_hass
name: Docker Running
entity: script.docker_restart_hass
icon: 'mdi:backup-restore'
type: divider
entity: sensor.ha_available_version
entity: sensor.ha_running_version
icon: 'mdi:information-outline'
entity: sensor.hacs
type: divider
entity: sensor.docker_hass_cpu_use
entity: sensor.docker_hass_memory_use
entity: sensor.docker_hass_memory_use_percent
show_header_toggle: false
title: Home Assistant Docker
type: entities

entities:

entity: binary_sensor.sonoff_update_available
entity: sensor.sonoff_firmware_version_available
entity: sensor.meye_sonoff_firmware
entity: sensor.ender3_sonoff_firmware
entity: sensor.washing_sonoff_firmware
entity: sensor.sensor01_sonoff_firmware
show_header_toggle: false
title: Sonoffs Firmware Version
type: entities

cards:

entity: switch.docker_watchtower
hold_action:
action: toggle
icon: 'mdi:content-duplicate'
icon_height: 50px
name: Update Docker Containers
show_icon: true
show_name: true
tap_action:
action: more-info
type: entity-button
entity: script.update_sonoffs
hold_action:
action: toggle
icon: 'mdi:content-duplicate'
icon_height: 50px
name: Update Sonoff Devices
show_icon: true
show_name: true
tap_action:
action: more-info
type: entity-button
type: horizontal-stack

card:
entities:
- entity: sensor.docker_watchtower_cpu_use
type: history-graph
conditions:

entity: switch.docker_watchtower
state: 'on'
type: conditional

card:
entities:
- entity: sensor.docker_watchtower_memory_use
type: history-graph
conditions:

entity: switch.docker_watchtower
state: 'on'
type: conditional

entities:

entity: switch.docker_nginx
name: Docker Running
entity: script.docker_restart_nginx
icon: 'mdi:backup-restore'
type: divider
entity: sensor.nginx_available_version
icon: 'mdi:information-outline'
entity: sensor.docker_nginx_cpu_use
entity: sensor.docker_nginx_memory_use
entity: sensor.docker_nginx_memory_use_percent
show_header_toggle: false
title: NginX - Let's Encrypt Docker
type: entities

entities:

entity: switch.docker_zigbee2mqtt
name: Docker Running
entity: script.docker_restart_zigbee2mqtt
icon: 'mdi:backup-restore'
type: divider
entity: sensor.zigbee2mqtt_available_version
icon: 'mdi:information-outline'
entity: sensor.docker_zigbee2mqtt_cpu_use
entity: sensor.docker_zigbee2mqtt_memory_use
entity: sensor.docker_zigbee2mqtt_memory_use_percent
show_header_toggle: false
title: Zigbee2MQTT Docker
type: entities

entities:

entity: switch.docker_mqtt
name: Docker Running
entity: script.docker_restart_mqtt
icon: 'mdi:backup-restore'
type: divider
entity: sensor.mosquitto_available_version
icon: 'mdi:information-outline'
entity: sensor.docker_mqtt_cpu_use
entity: sensor.docker_mqtt_memory_use
entity: sensor.docker_mqtt_memory_use_percent
show_header_toggle: false
title: Mosquitto MQTT Docker
type: entities

card:
entity: script.ip_ban_clear
hold_action:
action: toggle
icon: 'mdi:lock-reset'
icon_height: 50px
tap_action:
action: more-info
type: entity-button
conditions:

entity: persistent_notification.ip_ban
state: notifying
type: conditional

cards:

content: |
Add New Devices

type: markdown

entity: switch.zigbee_discovery
hold_action:
action: none
icon: 'mdi:power'
icon_height: 50px
name: Enable Zigbee Joining
show_icon: true
show_name: true
tap_action:
action: toggle
type: entity-button

content: >
Re-Sync Google Assistant Devices

Say "Ok Google, sync home control devices"

If not appearing still visit and try again:
https://console.actions.google.com/u/0/project/hass-/simulator
type: markdown
type: vertical-stack
icon: ''
title: Server Admin

badges: []
cards:

entity: sensor.ikea_dimmer_battery
max: 100
min: 0
name: Dimmer Battery
severity:
green: 100
red: 5
yellow: 18
theme: default
type: gauge
entity: sensor.xiaomi_switch_battery
max: 100
min: 0
name: Switch-Living Room Battery
severity:
green: 100
red: 20
yellow: 0
theme: default
type: gauge
title: Battery Levels

badges: []
cards:

entity: sensor.fireplace_linkquality
max: 100
min: 0
name: Light-Fireplace Link Quality
severity:
green: 30
red: 5
yellow: 10
theme: default
type: gauge
unit: '%'
entity: sensor.kitchen_linkquality
max: 100
min: 0
name: Light-Kitchen Link Quality
severity:
green: 30
red: 5
yellow: 10
theme: default
type: gauge
unit: '%'
entity: sensor.living_room_linkquality
max: 100
min: 0
name: Light-Living Room Link Quality
severity:
green: 30
red: 5
yellow: 10
theme: default
type: gauge
unit: '%'
entity: sensor.ikea_dimmer_linkquality
max: 100
min: 0
name: Dimmer Link Quality
severity:
green: 0
red: 0
yellow: 0
theme: default
type: gauge
unit: '%'
entity: sensor.xiaomi_switch_linkquality
max: 100
min: 0
name: Switch-Living Room Link Quality
severity:
green: 0
red: 0
yellow: 0
theme: default
type: gauge
unit: '%'
entity: sensor.0x000d6f000e056cfd_linkquality
max: 100
min: 0
name: Sensor-Front Door Link Quality
severity:
green: 0
red: 0
yellow: 0
theme: default
type: gauge
unit: '%'
entities:

entity: sensor.zigbee2mqtt_bridge_state
type: entities

entity: sensor.meye01_status
max: 100
min: 0
name: Switch-MEYE01 Link
severity:
green: 0
red: 0
yellow: 0
theme: default
type: gauge
unit: '%'
entity: sensor.ender3_status
max: 100
min: 0
name: Switch-Ender3 Link
severity:
green: 0
red: 0
yellow: 0
theme: default
type: gauge
unit: '%'
title: Wireless Levels
`

Thanks! This will really help.

Can't reproduce any more. Closing for now. Feel free to reopen if needed


STM32F1 SPI Driver Implementation

Implementation of the SPI functionality for the STM32F103C8 microcontroller.

Request a review when the PR is cleaned up.


Why is RCP pruned based on min instead of mean values?

Analyze & fix before v4.1

Solution for 4.0: https://github.com/mlcommons/logging/tree/training_v4.0

All RCPs graph:

RCPs pruned by Mean:

All RCPs min epochs graph:

RCPs pruned by Min epochs:

@pgmpablo157321  Can you add mean and min graph per benchmark in the same graph?

07/18 training wg agreed to use RCP pruning with mean.


Incorrect text rendering

What steps will reproduce the problem?
1. I have download win_samples_2.zip unzip it and run.
2. The same issue exists then I have compile the project from
gwen-dotnet-master.zip

What is the expected output? What do you see instead?
All text in window looks like gray rectangles.

What version of the product are you using? On what operating system?
On linux with mono all works fine, but the problem exists at some (not all) pc
with win xp and win7

Please provide any additional information below.
Attached file is screenshot of problem

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 7 Oct 2014 at 12:10
Attachments:

tmp_10654-bug1424159666.png

Not reproducable for me


Non-lmer, non-Bayesian models to support

This is mostly just a checklist of the more important models we might want to support with fancy math. In theory, these are all supported automatically with broom (though we might want to have a general catchall way to show non-fancy formulas):

[x] Binary logistic (glm(..., family = binomial(link = "logit")))
[ ] Binary probit (glm(..., family = binomial(link = "probit")))
[ ] Ordered logistic (MASS::polr(..., method = "logistic") and ordered::clm(..., link = "logit"))
[ ] Ordered probit (MASS::polr(..., method = "probit") and ordered::clm(..., link = "probit"))
[ ] Multinomial logistic (nnet::multinom())
[ ] Survival regression (survival::Surv())
[ ] Multiple ANOVA (stats::manova())

Nice. Not sure what math it involves, but what do you think about stats::manova()?

Sure! Just added it

betareg and DirichletReg?
pscl:: zeroinfl?

So with probit, how do we want to structure the LHS and RHS? Pr(Y = 1 | X) = Φ(β0 + β1X1 + etc.)? Or is that too complicated?
Once we figure that out, adding ordered probit will be trivial

I like that. The only issue is we'll need to swap extract_rhs to use S3 methods and implement this as a new method, but we were probably going to have to do that at some point anyway. If it ends up being too difficult we can always put it off for the next version, but I don't think it would be too bad (or at least I hope).

Yeah, the RHS is going to need stuff now bc φ, but it shouldn't be too bad.
Any ideas for notation for multinomial logit, survival, and multiple ANOVA?
Multinomial could be like ordered logit:
\log \frac{P(Y = \operatorname{outcome_1})}{P(Y = \operatorname{outcome\_base\_case})} = RHS \\
\log \frac{P(Y = \operatorname{outcome_2})}{P(Y = \operatorname{outcome\_base\_case})} = RHS \\
...

Survival models are complex and idk the best approach (nothing here looks simple)
Also don't know best way to do MANOVA (no clear regression-like syntax here - @jrosen48 might have ideas

Yeah I like that for multinomial. I have no idea on survival and MANOVA, honestly, but could do some looking into it.
Do we still want to support ordered::clm too? I haven't looked into that at all. If the output from broom::tidy is the same or basically the same it should be easy though.
Also, should we have the goal to support all of these before the initial release? Or get the release out basically now and develop these for v0.2?
Last question - do you want to take an initial stab at probit or should I? I might have some time later tonight I could devote to it if you haven't already started (or if you just want to).

I’m on it already, and also the clm ologit. It works with broom, so it
should be easy
I think probit + ordered probit and logit should be ready for initial
release, then multinomial and gang can come later
On July 29, 2020 at 19:16:23, Daniel Anderson<EMAIL_ADDRESS>wrote:

Yeah I like that for multinomial. I have no idea on survival and MANOVA,
honestly, but could do some looking into it.
Do we still want to support ordered::clm too? I haven't looked into that
at all. If the output from broom::tidy is the same or basically the same
it should be easy though.
Also, should we have the goal to support all of these before the initial
release? Or get the release out basically now and develop these for v0.2?
Last question - do you want to take an initial stab at probit or should I?
I might have some time later tonight I could devote to it if you haven't
already started (or if you just want to).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/datalorax/equatiomatic/issues/32#issuecomment-665978101,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAR7P6AVVUDU25KNW7AHIDR6CUUPANCNFSM4HUX3FZQ
.

Perfect!


Export Distro doesn't send to new registered clients

POST http://localhost:48071/api/v1/registration
{
..
}

Doesn't effect the Export service until the service is restarted

This is even a problem for the rules engine that registers when it bootstraps.  On start of the entire system, the export-distro has to be restarted in order to pick up the bootstrap registrations of services like rules engine.

It seems like a regression in the master I think it used to work in 0.6.1

Here's the root cause on this.
1.) During the Delhi development cycle, a change was made to drive the numeric portion of the interval at which the client monitor updates itself via configuration instead of a static value. A millisecond value (15000) was put into configuration and the code was not changed accordingly. What had originally been defined like this
time.Sleep(time.Second * time.Duration(15))
Became this
time.Sleep(time.Second * time.Duration(params.Interval))
Where params.Interval == 15000.
2.) Since we start all services via Docker with --consul enabled, the service clients go out to Consul and look at the registered services for their endpoint information. In the docker-compose, export-client is started before export-distro. When the distro client in the export-client service attempted to load an endpoint from Consul, there was nothing there because export-distro wasn't up yet. Therefore, the distro client was empty and wouldn't refresh for 15000 seconds.
3.) Once that was resolved, I had to eliminate setting the "Path" property on the distro client params struct to "/". Doing so caused faulty URLs to be built like so:
NotifyRegistrations url=http://edgex-export-distro:48070//api/v1/notify/registrations
ERROR: 2018/12/06 22:48:00 error from distro: 404 - 404 page not found

Notice the double slash after the port number.

With delhi PR #898 merged, will create a duplicate PR against master today.

Should be able to close this issue now given the above 2 PRs


create tutorial examples for documentation

To help users understand the utility of this library, it's always useful to have informative tutorials in the documentation to illustrate how one can use it in various scenarios.
This is a stub issue for creating a few tutorial pages for a diverse set of use cases (TBD)

I think as much.
I'm not taking this task, but I can contribute with my ipynb notes, user and dev, somewhere in the repo.
Just tell me, please, where I can put them, in order to be useful.

@cosmicBboy  I use pandas a lot and I would like to create tutorial examples from some of my more generalized use cases.  In doing so, I hope to have a better understanding of pandera.

sounds good @jekwatt! I'd recommend creating a tutorials directory in the root pandera repo and creating a jupyter notebook in there.

@cosmicBboy, I would like to contribute to the tutorials and understand how to implement panderas in regular use with pandas DF.

great, thanks @ak1920 !


[fix] Fix changing detection status to OFF

There was a problem with CodeChecker when .clang-tidy configration
file is used. If we enabled a checker in this config file and we
do not enabled it explicitly in CodeChecker if we stored the results
to the server these reports are marked as OFF.
With this patch if we store a report directory to the server then a
bug which can be found in this report directory can not be marked as
OFF so the detection status will be calculated properly.

 Here is an overview of what got changed by this pull request:

Complexity decreasing per file
==============================
+ web/tests/functional/detection_status/test_detection_status.py  -2

Clones added
============
- web/tests/functional/detection_status/test_detection_status.py  4

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity decreasing per file
==============================
+ web/tests/functional/detection_status/test_detection_status.py  -2

Clones added
============
- web/tests/functional/detection_status/test_detection_status.py  4

See the complete overview on Codacy


Port the visualization example from bl.ocks.org into the repository

connect the bl.ocks.org content to repo


Allow multiple users to use the app at once

Currently, only one user can use the app at once. This is pretty lame so I'm going to attempt to store persistent data in firebase and allow multiple users at the same time.

Issue too broad. I'm moving to more refined issues rather than huge features like this.


kafka-net .Net Core version

I converted this library to .net core because I needed it for the project with target .net core 2.1.
https://github.com/snmslavk/kafka-net-core

In addition to your nuget:kafka-net-core, it seems someone else has also published nuget:kafka-net-for-dotnet-core but theirs is without the source code.
As a user of kafka-net, I think it's definitely a valuable conversion. :)


Relocations aren't reflected ELF  headers

Section headers have "address" and "offset" fields, we should display virtual addresses in the "address"

This also applied to program headers; eg. this binary relocated to 0x400000:

It would be nice to be able to show both the resolved address as well as the original virtual address.
Likely related to #2092, in that we need some custom rendered for this as well.

This also affects PE, where address in data directory entry are all RVA, and not VA:
00400100      struct PE_Data_Directory_Entry importTableEntry =
00400100      {
00400100          uint32_t virtualAddress = 0x6000
00400104          uint32_t size = 0x6ec
00400108      }


Fix but in coerce when Rails 5 params are passed in

Since parameters in Rails 5 no longer sub class from Hash and blow up
when you try to call to_hash on them when they are not permitted the
coerce method in Virtus was no longer working. Since the hash here is
not mass assigned but instead only permits known attributes it is safe
to call .to_unsafe_hash if it is defined on the attributes. If not we
fall back to the previous behavior.
This also adds specs to capture the bahavior I was seeing on Rails 5.

#388


MB-8853 Fix estimated and actual weights for shuttling service items

Description
This PR makes the estimated and actual weights for shuttling service items optional again. For additional context: https://ustcdp3.slack.com/archives/CP6F568DC/p1627338724088900
Setup
To test, complete the following steps:
To run the tests execute make server_test
To test the createMTOServiceItem endpoint complete the following steps using postman:

Start your local server
hit the fetchMTOUpdates endpoint
Select a move with an existing shipment and grab the shipment and move IDs.
Hit the createMTOServiceItem endpoint with the following body

{
    "modelType": "MTOServiceItemShuttle",
    "moveTaskOrderID": "<YOUR MOVE ID>",
    "mtoShipmentID": "<YOUR SHIPMENT ID>",
    "status": "SUBMITTED",
    "reServiceCode": "DOSHUT",
    "description": "description",
    "reason": "reason",
    "estimatedWeight": 4200
}

This will create the DOSHUT service item.
Code Review Verification Steps

[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change

Messages

:book:
:link: MB-8853

  Generated by :no_entry_sign: dangerJS against cbbcef2878e3baf4fb333129a26d749e5ebb09cc


Do not override treesitter lua highlighting with sumneko lua highlighting

I noticed that when opening a lua file, the highlighting initially looks really nice. (Thanks treesitter!) But then once sumneko_lua is done initializing, the highlighting changes slightly (specifically, parent fields turn back to white). This is because sumneko overrides treesitter's highlighting with its own. So this PR disables the sumneko highlighting so we can keep the pretty treesitter one.
This is the field:
https://github.com/sumneko/lua-language-server/wiki/Settings#semanticenable
Signed-off-by: David Ward<EMAIL_ADDRESS>

I'm still a bit of a noob when it comes to LSP, with this configuration could there ever be a conflict between treesitter highlighting and LSP error reporting? For example, if treesitter and sumneko parse a file differently and disagree on what a symbol is, could it lead to problems?

According to the sumneko documentation, the entire semantic group of configuration properties only has to do with highlighting. I guess it could be possible that treesitter's grammar could mistakenly consider a token to be something different than what sumneko thinks it is, however the only repercussion of that would be a mis-coloring. But the LSP behavior would not be affected. But again, this is according to the docs. If the docs are wrong or misleading, then I could be wrong.

Thanks for the links to the docs. I agree with you. Any error scenario like this is probably going to be very infrequent.

I wonder if it's just because this colorscheme hasn't been updated yet to have the semantic highlights be good colors? I'll have to follow up on that to find that out.

use is not a keyword -- it's a variable (actually, it's a parameter passed to the function). My guess is it's highlighting parameters as different things than regular variables. I think that's personal preference on what you'd want to do.
It'd be helpful to see screenshots, but I'm unlikely to turn it off by default I think. I'll try and do some testing this week though and maybe I'll end up agreeing with you haha

Oops, yeah, you're right: use is a parameter. But vim.fn is a field, and both are getting clobbered. So it's not just a parameter-thing. Thanks again; I appreciate your time on this. I know it's small, but it's annoying to see colors unintentionally change (for the worse) a couple seconds after you open the file.

@errantepiphany Maybe u can try :TSHighlightCapturesUnderCursor to see which hilight group is taking charge, a command from ts-playground

If you've got a very recent Neovim you can also now do: :Inspect and :Inspect! (for pretty-print)

Yeah, let's close for now (and fix any upstream issues if they exist). Thanks for doing all this tracking down and no worries at all :) Thanks for the detailed write ups!


Unable to set body mapping template for serverless function

Description:In sam template for serverless function type unable to provide body mapping template definition when the lambda integration type is used
Events:
GetEvent:
Type: Api
StageName: abc
Properties:
Path: /api/test-events
Method: get
Observed result:
Expected result:

Issue isn't very clear. SAM API events currently provide method definitions for the DefinitionBody of an API if no existing swagger is found by SAM.


Communications for Wastewater Locations - New Demand

#Privacy of Information and Protection:
Your opinion is your personal information. Please do not include any information which identifies you or others in your response.
#Description:
#Outcome:

[ ]  Intake form received
[ ]  New demand created
[ ] Await updated resource plan and proposed project time

#To Complete this ticket:

[ ]
[ ]
[ ]

Added to pending demand backlog, this ticket is now closed


lint en.json locales file

make sure we don't have another  #2107

check that it fails: https://ci.woodpecker-ci.org/repos/3780/pipeline/7033/24
check that it will pass: https://ci.woodpecker-ci.org/repos/3780/pipeline/7037/24

oh, sorry, did not see that this also fixes problem that I fixed, now there are conflict :(

resolved :rocket:


[Bug] Your Bug Report Here Requesting changes to 'Create a Role' (create-role)

Describe the bug field is entitlements not Entitlements
To Reproduce
try to Create Role with Entitlements.  role is created, but entitlements do not get added to it
try to create role with lowercase entitlements.  role is created, and the provided Entitlements ARE added
Expected behavior
Following the API Spec should add entitlements to the newly created role
Actual behavior
as written, Entitielemts is ignored.
Screenshots

Additional context
Please update field schema to lowercase entitlements, and update sample API as well to lowercase entitlements

@colin-mckibben-sp  pushed a change to the code for this, and this should be resolved shortly.


release v3.0.1

closes #787
Release checklist

[x] Ensure all milestoned issues/PRs are addressed, or reassign to a new milestone.
[x] Add the dont merge label to all PRs that are close to be ready to merge (or merge them if they are ready) in capa and capa-rules.
[x] Ensure the CI workflow succeeds in master.
[x] Ensure that python scripts/lint.py rules/ --thorough succeeds (only missing examples  offenses are allowed in the nursery).
[x] Review changes

capa https://github.com/fireeye/capa/compare/<last-release>...master
capa-rules https://github.com/fireeye/capa-rules/compare/<last-release>...master

[x] Update CHANGELOG.md

Do not forget to add a nice introduction thanking contributors
Remember that we need a major release if we introduce breaking changes
Sections: see template below
Update Raw diffs links
Create placeholder for master (unreleased) section## master (unreleased)

### New Features

### Breaking Changes

### New Rules (0)

-

### Bug Fixes

### capa explorer IDA Pro plugin

### Development

### Raw diffs
- [capa <release>...master](https://github.com/fireeye/capa/compare/<release>...master)
- [capa-rules <release>...master](https://github.com/fireeye/capa-rules/compare/<release>...master)

[x] Update capa/version.py
[x] Create a PR with the updated CHANGELOG.md and capa/version.py. Copy this checklist in the PR description.
[ ] After PR review, merge the PR and create the release in GH using text from the CHANGELOG.md.
[ ] Verify GH actions upload artifacts, publish to PyPI and create a tag in capa rules upon completion.
[ ] Spread the word
[ ] Update internal service

Checklist

[ ] No CHANGELOG update needed

[x] No new tests needed

[x] No documentation update needed

Thanks, finalizing this now!


Security API version 2019-08-01

Service Package Request
👋
We've been asked (offline) if we can migrate to a stable version of the Security API, rather than using the Preview API (2017-08-01-preview) that we're currently using. As a part of this we've had a PR opened to update Terraform to use API version 2019-08-01) - however it appears that most of the resources for this don't exist in this SDK (or the Swagger).
Taking a look at the Swagger it appears that different versions of the Security API offer different functionality - but the API versions aren't additive; thus it's not possible to easily migrate from the older -> newer API versions - which would be fine for a resource which has been removed, but in this instance it appears both are still current? In addition they appear to use a different versioning scheme to the rest of the Resource Provider SDK's for some reason?
Would it be possible for someone to confirm if the API's are additive, rather than outright replacing each other; so that we're able to determine a path forward onto the stable API version here? One example of this is the Advanced Protection Client which appears to only be available in API version 2017-08-01-preview.
Downstream issue in Terraform: https://github.com/terraform-providers/terraform-provider-azurerm/pull/4509
Thanks!

@loarabia is there any update available here? :)

@tombuildsstuff let me ping the team on email.

hi @tombuildsstuff,
The API is indeed additive and the last API version of each type should be used.
we will keep this behavior in the future, but we're going to reduce the number of versions that we use (currently we are aligning towards "2019-01-01-preview" and "2019-01-01")
you can follow the latest composite to see the most current subset of types and versions (currently it is package-composite-v3)

Hi @tombuildsstuff does switching from security/v1.0 to security/v3.0 work? If so, I will close this issue.


Make sticky cognizent of top and bottom margins.

So we're using sticky for a bunch of navigational items, that may or may not have margins on the top or bottom (typically the bottom).
The library doesn't take this margin into account when determining the height, and so text gets bumped around when it gets activated. Not cool... We can remove those margins, but then that means we have to add those margins to other things, and it just feels like a bit of a hack.
Is there a better way I'm missing, or should I create a PR?
Example:
https://jsfiddle.net/heathdutton/85k7g8vt/5/

I am seeing this as well. I have made a sticky module in Joomla and the modules have a margin-bottom of 30px.
When I enable the sticky plugin for that module the margin gets ignored and the module underneath it gets put right against the bottom of the sticky module (when the module is not in sticky mode).
It's a little weird when you load the page  as you see the screen render correctly with the modules equally spaced on the left and then you will see the modules under the sticky module  jump up to be right under the sticky module.

Okay I found a fix for this. In the file jquery.sticky.js you should find about 5 occurrences of
.outerHeight()
It references of the height of the sticky item. Replace it with:
.outerHeight(true)
This tells jQuery to include the margin in the height: http://api.jquery.com/outerheight/
Not sure why this is not on for the plugin by default. There probably is a reason. If not, lets make this the default behavior. If there is a reason then lets make it a configurable option for the sticky item.
Thanks

Take a look at #213. I put links to a fork that contains a script addresses this.


teleport --diag-addr is not present in cli help

--diag-addr is documented in the web docs, but not in the printed CLI help docs

This is another bug, that we should add.


Separate man output files depend on 32 and 64 version...

There is a issue where both man for 32 and 64 bit version have the same name:
install(FILES "${CMAKE_SOURCE_DIR}/man/apulse.1" DESTINATION share/man/man1)
would be nice if:

64 bit get:
install(FILES "${CMAKE_SOURCE_DIR}/man/apulse.1" DESTINATION share/man/man1)
-32 bit get:
install(FILES "${CMAKE_SOURCE_DIR}/man/apulse32.1" DESTINATION share/man/man1)

Isn't that what -doc or some other arch-independent packages are for?

That mean if both versions x86 and x86_64 are builded and used at systemm, that chosen distro package maintainer need to care about adjust and rename man files, bc both will get the same naming of output man files... ? Greetings...


After running the program for a period of time, it crashes

After running the program for a period of time, a fatal error may occur, and a critical message was obtained in WinDbg.exe: Windows Win32.PInvoke.WaitMessage()

You will need to provide more detailed .NET diagnostics.
Also WTelegramClient is a library, not a program, so maybe the problem is in your program.

not enough details


Camera vs CameraData Redundancy

Stream of consciousness here...wondering if there is an advantage to streamlining the Camera / CameraData framework. The cameras dictionary and the camera array were developed at different times but can probably stand to be integrated with each other... should help to avoid duplication during session management...

reflecting on it, this is not important at all


Dead link http://www.visualstudio.com/integrate/get-started/get-started-service-hooks-creating-and-managing-vsi

Found in docs/service-hooks/services/campfire.md

Link was replaced in that article and is fixed