nodejs builds different on my system, compared to inside a docker container

Issue description
When I try to run nodejs on my nixos system, it attempts to build nodejs from source, rather than use the binary cache
Steps to reproduce
Run this command on my system, you can see it attempts to build nodejs from source, this is bad:
$ nix-shell -p nodejs --dry-run
these derivations will be built:
  /nix/store/gxr007lvkx23j75pdp94pr44ivgrwyy3-nodejs-18.15.0.drv
these paths will be fetched (38.69 MiB download, 39.19 MiB unpacked):
  /nix/store/3fah1gvzz9a1la4dr1qp4r8jvk22iz82-pkg-config-0.29.2
  /nix/store/7g1ahlh4arijw4gzggbcjdz00gjpp4b2-node-v18.15.0.tar.xz
  /nix/store/9fqaqjjjvgk8fcy05319dhpgg7zwhvfx-http-parser-2.9.4
  /nix/store/liawqp5fjqna6gnrpp8rs3x1gfb5fxjj-pkg-config-wrapper-0.29.2

Here is the derivation that's being used for nodejs, nix show-derivation /nix/store/gxr007lvkx23j75pdp94pr44ivgrwyy3-nodejs-18.15.0.drv:
{
  "/nix/store/gxr007lvkx23j75pdp94pr44ivgrwyy3-nodejs-18.15.0.drv": {
    "outputs": {
      "libv8": {
        "path": "/nix/store/9ip3sqyc3f0m1306rqsny84hlgxsbcf9-nodejs-18.15.0-libv8"
      },
      "out": {
        "path": "/nix/store/q8pgawgndzhjfxns3mrcb7aahkr8kxc6-nodejs-18.15.0"
      }
    },
    "inputSrcs": [
      "/nix/store/6xg259477c90a229xwmb53pdfkn6ig3g-default-builder.sh",
      "/nix/store/ay9ps6p97mf12nybf9d4r3nyina81b87-setup-hook.sh",
      "/nix/store/cg9pf70w99aa7nbwm08kwchplb6rqshc-revert-arm64-pointer-auth.patch",
      "/nix/store/cqn0y2wklslppakf9zwrwm6c139mh9dj-disable-darwin-v8-system-instrumentation.patch",
      "/nix/store/z3xpyq84lw3ij13g0g3khcy136da1g7g-bypass-darwin-xcrun-node16.patch"
    ],
    "inputDrvs": {
      "/nix/store/06z6fgi6pxznzasvyqg8za3rv2bqkgcp-python3-3.10.10.drv": [
        "out"
      ],
      "/nix/store/5l92g2q5ymaii3pz7s36y88madg6rs54-pkg-config-wrapper-0.29.2.drv": [
        "out"
      ],
      "/nix/store/97qra9ndw8pyfi55m2d6898gqr5nk3fq-which-2.21.drv": [
        "out"
      ],
      "/nix/store/fvhxsrg9vbabmyh7xirgcrmfmg31pma2-libuv-1.44.2.drv": [
        "out"
      ],
      "/nix/store/mbw46idlsjk79gx4w91kv7q1sqjx9rzh-openssl-3.0.8.drv": [
        "dev",
        "out"
      ],
      "/nix/store/p38k93galz1wjbz7icw6plg8gznlbgbm-http-parser-2.9.4.drv": [
        "out"
      ],
      "/nix/store/pc8gk9qcc2jmfsjlrvjx2h0yvlciq82g-icu4c-72.1.drv": [
        "dev"
      ],
      "/nix/store/q0ml0xhn7vlranc9h2gh7kwy357jmr4h-bash-5.2-p15.drv": [
        "out"
      ],
      "/nix/store/w184rg11rf6ridzdxhq6w9jm70706wf0-stdenv-linux.drv": [
        "out"
      ],
      "/nix/store/wfb8f6nsrnfhpw7ya1dwj3k9d4vx6li1-gcc-wrapper-12.2.0.drv": [
        "out"
      ],
      "/nix/store/whrmqngan2zssd4cw9pfzrw686v13cc9-zlib-1.2.13.drv": [
        "dev",
        "out"
      ],
      "/nix/store/wvkdnjafainbrlmn3kxh3zgvcpypda0k-node-v18.15.0.tar.xz.drv": [
        "out"
      ],
      "/nix/store/xhrw8ihf1s7x971xmhc84i3p2xmxc4hq-coreutils-9.1.drv": [
        "out"
      ]
    },
    "platform": "x86_64-linux",
    "builder": "/nix/store/zlf0f88vj30sc7567b80l52d19pbdmy2-bash-5.2-p15/bin/bash",
    "args": [
      "-e",
      "/nix/store/6xg259477c90a229xwmb53pdfkn6ig3g-default-builder.sh"
    ],
    "env": {
      "CC_host": "cc",
      "CXX_host": "c++",
      "__contentAddressed": "",
      "__structuredAttrs": "",
      "buildInputs": "/nix/store/lf6arf2qj94qs6bkzfl2y75chb7awmx9-zlib-1.2.13-dev /nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2 /nix/store/8m54v44ggv77z9hc7y0jiyii6r99hw5a-openssl-3.0.8-dev /nix/store/9fqaqjjjvgk8fcy05319dhpgg7zwhvfx-http-parser-2.9.4 /nix/store/4kzp60197xfqmnz6iqnwx5zk7w24qwk9-icu4c-72.1-dev",
      "builder": "/nix/store/zlf0f88vj30sc7567b80l52d19pbdmy2-bash-5.2-p15/bin/bash",
      "cmakeFlags": "",
      "configureFlags": "--shared-libuv --shared-libuv-libpath=/nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2/lib --shared-openssl --shared-openssl-libpath=/nix/store/ijk9j536zs30kha06rr966gplwxd7fbg-openssl-3.0.8/lib --shared-zlib --shared-zlib-libpath=/nix/store/2ldgh1qis9p4zf8bgsdm7897gw8vv36g-zlib-1.2.13/lib --with-intl=system-icu --without-dtrace",
      "configurePlatforms": "",
      "depsBuildBuild": "/nix/store/nlgyw2fv0cm8rkz8qm1jyw78vyif1bl9-gcc-wrapper-12.2.0 /nix/store/8m54v44ggv77z9hc7y0jiyii6r99hw5a-openssl-3.0.8-dev /nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2 /nix/store/lf6arf2qj94qs6bkzfl2y75chb7awmx9-zlib-1.2.13-dev",
      "depsBuildBuildPropagated": "",
      "depsBuildTarget": "",
      "depsBuildTargetPropagated": "",
      "depsHostHost": "",
      "depsHostHostPropagated": "",
      "depsTargetTarget": "",
      "depsTargetTargetPropagated": "",
      "doCheck": "",
      "doInstallCheck": "",
      "dontDisableStatic": "1",
      "enableParallelBuilding": "1",
      "enableParallelChecking": "1",
      "enableParallelInstalling": "1",
      "libv8": "/nix/store/9ip3sqyc3f0m1306rqsny84hlgxsbcf9-nodejs-18.15.0-libv8",
      "mesonFlags": "",
      "moveToDev": "",
      "name": "nodejs-18.15.0",
      "nativeBuildInputs": "/nix/store/41z9sjq6821qbfiqcqz9y67mkjr9d7cs-which-2.21 /nix/store/liawqp5fjqna6gnrpp8rs3x1gfb5fxjj-pkg-config-wrapper-0.29.2 /nix/store/fdqpyj613dr0v1l1lrzqhzay7sk4xg87-python3-3.10.10",
      "out": "/nix/store/q8pgawgndzhjfxns3mrcb7aahkr8kxc6-nodejs-18.15.0",
      "outputs": "out libv8",
      "patches": "/nix/store/cqn0y2wklslppakf9zwrwm6c139mh9dj-disable-darwin-v8-system-instrumentation.patch /nix/store/z3xpyq84lw3ij13g0g3khcy136da1g7g-bypass-darwin-xcrun-node16.patch /nix/store/cg9pf70w99aa7nbwm08kwchplb6rqshc-revert-arm64-pointer-auth.patch",
      "pname": "nodejs",
      "postInstall": "PATH=$out/bin:$PATH patchShebangs $out\n\nmkdir -p $out/share/bash-completion/completions/\nHOME=$TMPDIR $out/bin/npm completion > $out/share/bash-completion/completions/npm\nfor dir in \"$out/lib/node_modules/npm/man/\"*; do\n  mkdir -p $out/share/man/$(basename \"$dir\")\n  for page in \"$dir\"/*; do\n    ln -rs $page $out/share/man/$(basename \"$dir\")\n  done\ndone\n\n\n# install the missing headers for node-gyp\ncp -r /nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2/include/* /nix/store/8m54v44ggv77z9hc7y0jiyii6r99hw5a-openssl-3.0.8-dev/include/* /nix/store/lf6arf2qj94qs6bkzfl2y75chb7awmx9-zlib-1.2.13-dev/include/* $out/include/node\n\n# assemble a static v8 library and put it in the 'libv8' output\nmkdir -p $libv8/lib\npushd out/Release/obj.target\nfind . -path \"./torque_*/**/*.o\" -or -path \"./v8*/**/*.o\" | sort -u >files\nar -cqs $libv8/lib/libv8.a @files\n\npopd\n\n# copy v8 headers\ncp -r deps/v8/include $libv8/\n\n# create a pkgconfig file for v8\nmajor=$(grep V8_MAJOR_VERSION deps/v8/include/v8-version.h | cut -d ' ' -f 3)\nminor=$(grep V8_MINOR_VERSION deps/v8/include/v8-version.h | cut -d ' ' -f 3)\npatch=$(grep V8_PATCH_LEVEL deps/v8/include/v8-version.h | cut -d ' ' -f 3)\nmkdir -p $libv8/lib/pkgconfig\ncat > $libv8/lib/pkgconfig/v8.pc << EOF\nName: v8\nDescription: V8 JavaScript Engine\nVersion: $major.$minor.$patch\nLibs: -L$libv8/lib -lv8 -pthread -licui18n\nCflags: -I$libv8/include\nEOF\n",
      "postPatch": "patchShebangs .\n\n# fix tests\nfor a in test/parallel/test-child-process-env.js \\\n         test/parallel/test-child-process-exec-env.js \\\n         test/parallel/test-child-process-default-options.js \\\n         test/fixtures/syntax/good_syntax_shebang.js \\\n         test/fixtures/syntax/bad_syntax_shebang.js ; do\n  substituteInPlace $a \\\n    --replace \"/usr/bin/env\" \"/nix/store/arbxkmcgv9h8pjgj95c6d7r86yb77rl5-coreutils-9.1/bin/env\"\ndone\n",
      "propagatedBuildInputs": "",
      "propagatedNativeBuildInputs": "",
      "setOutputFlags": "",
      "setupHook": "/nix/store/ay9ps6p97mf12nybf9d4r3nyina81b87-setup-hook.sh",
      "src": "/nix/store/7g1ahlh4arijw4gzggbcjdz00gjpp4b2-node-v18.15.0.tar.xz",
      "stdenv": "/nix/store/5s1yg5l36wzgy1dj0vv1ibarc4g7vrdr-stdenv-linux",
      "strictDeps": "",
      "system": "x86_64-linux",
      "version": "18.15.0"
    }
  }
}

Compare this to running the same command in a nixos/nix docker container, on the last line you can see it fetches nodejs from the binary cache:
bash-5.1# nix-shell -p nodejs
these 64 paths will be fetched (135.05 MiB download, 587.74 MiB unpacked):
...
copying path '/nix/store/njh6p007ymbmcgas5l7sqqxfmm394zx1-nodejs-18.15.0' from 'https://cache.nixos.org'...

Here is the derivation that's being used inside the docker container, nix --extra-experimental-features nix-command show-derivation /nix/store/njh6p007ymbmcgas5l7sqqxfmm394zx1-nodejs-18.15.0
{
  "/nix/store/4gqcynvdkf6r2vknhs56sdjl6fqpcrwi-nodejs-18.15.0.drv": {
    "outputs": {
      "libv8": {
        "path": "/nix/store/60mrflih58pm47h687cqbxvb6igc9nc3-nodejs-18.15.0-libv8"
      },
      "out": {
        "path": "/nix/store/njh6p007ymbmcgas5l7sqqxfmm394zx1-nodejs-18.15.0"
      }
    },
    "inputSrcs": [
      "/nix/store/6xg259477c90a229xwmb53pdfkn6ig3g-default-builder.sh",
      "/nix/store/ay9ps6p97mf12nybf9d4r3nyina81b87-setup-hook.sh",
      "/nix/store/cg9pf70w99aa7nbwm08kwchplb6rqshc-revert-arm64-pointer-auth.patch",
      "/nix/store/cqn0y2wklslppakf9zwrwm6c139mh9dj-disable-darwin-v8-system-instrumentation.patch",
      "/nix/store/z3xpyq84lw3ij13g0g3khcy136da1g7g-bypass-darwin-xcrun-node16.patch"
    ],
    "inputDrvs": {
      "/nix/store/06z6fgi6pxznzasvyqg8za3rv2bqkgcp-python3-3.10.10.drv": [
        "out"
      ],
      "/nix/store/5l92g2q5ymaii3pz7s36y88madg6rs54-pkg-config-wrapper-0.29.2.drv": [
        "out"
      ],
      "/nix/store/97qra9ndw8pyfi55m2d6898gqr5nk3fq-which-2.21.drv": [
        "out"
      ],
      "/nix/store/fvhxsrg9vbabmyh7xirgcrmfmg31pma2-libuv-1.44.2.drv": [
        "out"
      ],
      "/nix/store/mbw46idlsjk79gx4w91kv7q1sqjx9rzh-openssl-3.0.8.drv": [
        "dev",
        "out"
      ],
      "/nix/store/p38k93galz1wjbz7icw6plg8gznlbgbm-http-parser-2.9.4.drv": [
        "out"
      ],
      "/nix/store/pc8gk9qcc2jmfsjlrvjx2h0yvlciq82g-icu4c-72.1.drv": [
        "dev"
      ],
      "/nix/store/q0ml0xhn7vlranc9h2gh7kwy357jmr4h-bash-5.2-p15.drv": [
        "out"
      ],
      "/nix/store/w184rg11rf6ridzdxhq6w9jm70706wf0-stdenv-linux.drv": [
        "out"
      ],
      "/nix/store/wfb8f6nsrnfhpw7ya1dwj3k9d4vx6li1-gcc-wrapper-12.2.0.drv": [
        "out"
      ],
      "/nix/store/whrmqngan2zssd4cw9pfzrw686v13cc9-zlib-1.2.13.drv": [
        "dev",
        "out"
      ],
      "/nix/store/wvkdnjafainbrlmn3kxh3zgvcpypda0k-node-v18.15.0.tar.xz.drv": [
        "out"
      ],
      "/nix/store/xhrw8ihf1s7x971xmhc84i3p2xmxc4hq-coreutils-9.1.drv": [
        "out"
      ]
    },
    "system": "x86_64-linux",
    "builder": "/nix/store/zlf0f88vj30sc7567b80l52d19pbdmy2-bash-5.2-p15/bin/bash",
    "args": [
      "-e",
      "/nix/store/6xg259477c90a229xwmb53pdfkn6ig3g-default-builder.sh"
    ],
    "env": {
      "CC_host": "cc",
      "CXX_host": "c++",
      "__structuredAttrs": "",
      "buildInputs": "/nix/store/lf6arf2qj94qs6bkzfl2y75chb7awmx9-zlib-1.2.13-dev /nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2 /nix/store/8m54v44ggv77z9hc7y0jiyii6r99hw5a-openssl-3.0.8-dev /nix/store/9fqaqjjjvgk8fcy05319dhpgg7zwhvfx-http-parser-2.9.4 /nix/store/4kzp60197xfqmnz6iqnwx5zk7w24qwk9-icu4c-72.1-dev",
      "builder": "/nix/store/zlf0f88vj30sc7567b80l52d19pbdmy2-bash-5.2-p15/bin/bash",
      "cmakeFlags": "",
      "configureFlags": "--shared-libuv --shared-libuv-libpath=/nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2/lib --shared-openssl --shared-openssl-libpath=/nix/store/ijk9j536zs30kha06rr966gplwxd7fbg-openssl-3.0.8/lib --shared-zlib --shared-zlib-libpath=/nix/store/2ldgh1qis9p4zf8bgsdm7897gw8vv36g-zlib-1.2.13/lib --with-intl=system-icu --without-dtrace",
      "configurePlatforms": "",
      "depsBuildBuild": "/nix/store/nlgyw2fv0cm8rkz8qm1jyw78vyif1bl9-gcc-wrapper-12.2.0 /nix/store/8m54v44ggv77z9hc7y0jiyii6r99hw5a-openssl-3.0.8-dev /nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2 /nix/store/lf6arf2qj94qs6bkzfl2y75chb7awmx9-zlib-1.2.13-dev",
      "depsBuildBuildPropagated": "",
      "depsBuildTarget": "",
      "depsBuildTargetPropagated": "",
      "depsHostHost": "",
      "depsHostHostPropagated": "",
      "depsTargetTarget": "",
      "depsTargetTargetPropagated": "",
      "doCheck": "",
      "doInstallCheck": "",
      "dontDisableStatic": "1",
      "enableParallelBuilding": "1",
      "enableParallelChecking": "1",
      "enableParallelInstalling": "1",
      "libv8": "/nix/store/60mrflih58pm47h687cqbxvb6igc9nc3-nodejs-18.15.0-libv8",
      "mesonFlags": "",
      "moveToDev": "",
      "name": "nodejs-18.15.0",
      "nativeBuildInputs": "/nix/store/41z9sjq6821qbfiqcqz9y67mkjr9d7cs-which-2.21 /nix/store/liawqp5fjqna6gnrpp8rs3x1gfb5fxjj-pkg-config-wrapper-0.29.2 /nix/store/fdqpyj613dr0v1l1lrzqhzay7sk4xg87-python3-3.10.10",
      "out": "/nix/store/njh6p007ymbmcgas5l7sqqxfmm394zx1-nodejs-18.15.0",
      "outputs": "out libv8",
      "patches": "/nix/store/cqn0y2wklslppakf9zwrwm6c139mh9dj-disable-darwin-v8-system-instrumentation.patch /nix/store/z3xpyq84lw3ij13g0g3khcy136da1g7g-bypass-darwin-xcrun-node16.patch /nix/store/cg9pf70w99aa7nbwm08kwchplb6rqshc-revert-arm64-pointer-auth.patch",
      "pname": "nodejs",
      "postInstall": "PATH=$out/bin:$PATH patchShebangs $out\n\nmkdir -p $out/share/bash-completion/completions/\nHOME=$TMPDIR $out/bin/npm completion > $out/share/bash-completion/completions/npm\nfor dir in \"$out/lib/node_modules/npm/man/\"*; do\n  mkdir -p $out/share/man/$(basename \"$dir\")\n  for page in \"$dir\"/*; do\n    ln -rs $page $out/share/man/$(basename \"$dir\")\n  done\ndone\n\n\n# install the missing headers for node-gyp\ncp -r /nix/store/wcdi96dabywjdc03kr844plhk8mcsk5s-libuv-1.44.2/include/* /nix/store/8m54v44ggv77z9hc7y0jiyii6r99hw5a-openssl-3.0.8-dev/include/* /nix/store/lf6arf2qj94qs6bkzfl2y75chb7awmx9-zlib-1.2.13-dev/include/* $out/include/node\n\n# assemble a static v8 library and put it in the 'libv8' output\nmkdir -p $libv8/lib\npushd out/Release/obj.target\nfind . -path \"./torque_*/**/*.o\" -or -path \"./v8*/**/*.o\" | sort -u >files\nar -cqs $libv8/lib/libv8.a @files\n\npopd\n\n# copy v8 headers\ncp -r deps/v8/include $libv8/\n\n# create a pkgconfig file for v8\nmajor=$(grep V8_MAJOR_VERSION deps/v8/include/v8-version.h | cut -d ' ' -f 3)\nminor=$(grep V8_MINOR_VERSION deps/v8/include/v8-version.h | cut -d ' ' -f 3)\npatch=$(grep V8_PATCH_LEVEL deps/v8/include/v8-version.h | cut -d ' ' -f 3)\nmkdir -p $libv8/lib/pkgconfig\ncat > $libv8/lib/pkgconfig/v8.pc << EOF\nName: v8\nDescription: V8 JavaScript Engine\nVersion: $major.$minor.$patch\nLibs: -L$libv8/lib -lv8 -pthread -licui18n\nCflags: -I$libv8/include\nEOF\n",
      "postPatch": "patchShebangs .\n\n# fix tests\nfor a in test/parallel/test-child-process-env.js \\\n         test/parallel/test-child-process-exec-env.js \\\n         test/parallel/test-child-process-default-options.js \\\n         test/fixtures/syntax/good_syntax_shebang.js \\\n         test/fixtures/syntax/bad_syntax_shebang.js ; do\n  substituteInPlace $a \\\n    --replace \"/usr/bin/env\" \"/nix/store/arbxkmcgv9h8pjgj95c6d7r86yb77rl5-coreutils-9.1/bin/env\"\ndone\n",
      "propagatedBuildInputs": "",
      "propagatedNativeBuildInputs": "",
      "setOutputFlags": "",
      "setupHook": "/nix/store/ay9ps6p97mf12nybf9d4r3nyina81b87-setup-hook.sh",
      "src": "/nix/store/7g1ahlh4arijw4gzggbcjdz00gjpp4b2-node-v18.15.0.tar.xz",
      "stdenv": "/nix/store/5s1yg5l36wzgy1dj0vv1ibarc4g7vrdr-stdenv-linux",
      "strictDeps": "",
      "system": "x86_64-linux",
      "version": "18.15.0"
    }
  }
}

From what I can see, the main difference between the two derivations is the version of nodejs-18.15.0-libv8 that's being used... on my system, I am using a custom one that's been built from source, instead of one from the binary cache?
How do I resolve this?
Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.24, NixOS, 23.05 (Stoat), 23.05pre474575.f00994e78cd`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.16`
 - channels(root): `"nixos, nixos-hardware"`
 - channels(aaron): `"home-manager, nixos-23.05pre476152.2362848adf8"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

If input to any derivation changes, the derivation itself changes and has to be compiled. This is not bug but a feature.
As for why libv8 changes on your machine - it must be some build input for that derivation which doesn't match with binary cache.

I fully agree with everything you say @turboMaCk , but I can't locate what that different input is, which causes my derivation to be different. I'll continue to search
I've attempted to do a recursive search of all derivations which are used in building nodejs - nix show-derivation -r /nix/store/gxr007lvkx23j75pdp94pr44ivgrwyy3-nodejs-18.15.0.drv, but there is no difference between my derivations and the one inside a nixos/nix docker container (apart from the final derivation).
in-case someone can spot something I can't, here are the derivations I compared:

nodejs-18.15.0.drv nixos/nix docker image derivation (correct)
nodejs-18.15.0.drv my derivation (incorrect)

Can you check that the nixpkgs version are the same on both systems?
You mentioned nixos-23.05pre476152.2362848adf8 check if the nixos/nix image has the same.

@RaitoBezarius here's what I get inside the nixos/nix docker container
bash-5.1# nix-shell -p nix-info --run "nix-info -m"
  - system: `"x86_64-linux"`
 - host os: `Linux 6.1.24`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.11.0`
 - channels(root): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

I don't know how useful that is, so I tried an alternative approach using niv. Here's the version of nixpkgs on my machine:
$ niv init
$ niv show
nixpkgs
  branch: release-21.05
  description: Nix Packages collection
  homepage:
  owner: NixOS
  repo: nixpkgs
  rev: 5f244caea76105b63d826911b2a1563d33ff1cdc
  sha256: 1xlgynfw9svy7nvh9nkxsxdzncv9hg99gbvbwv3gmrhmzc3sar75
  type: tarball
  url: https://github.com/NixOS/nixpkgs/archive/5f244caea76105b63d826911b2a1563d33ff1cdc.tar.gz
  url_template: https://github.com/<owner>/<repo>/archive/<rev>.tar.gz

And inside the docker container:
[nix-shell:/nix/var/nix/profiles/per-user/root/channels/nixpkgs]# niv init
[nix-shell:/nix/var/nix/profiles/per-user/root/channels/nixpkgs]# niv show
nixpkgs
  branch: release-21.05
  description: Nix Packages collection
  homepage:
  owner: NixOS
  repo: nixpkgs
  rev: 5f244caea76105b63d826911b2a1563d33ff1cdc
  sha256: 1xlgynfw9svy7nvh9nkxsxdzncv9hg99gbvbwv3gmrhmzc3sar75
  type: tarball
  url: https://github.com/NixOS/nixpkgs/archive/5f244caea76105b63d826911b2a1563d33ff1cdc.tar.gz
  url_template: https://github.com/<owner>/<repo>/archive/<rev>.tar.gz

As you can see, the docker is running a 21.05 (!!!!) nixpkgs, this is extremely old, unsupported and EOL.
I don't really use Docker and am not interested into it, but you should probably ping the person building those images and ask for an update, this is problematic.

After looking into that, it seems this might be misleading, can you actually run nix-shell -p nix-info --run "nix-info -m" in the Docker container so we can be certain it's running 21.05 or something else?

@RaitoBezarius sure:
$ docker run --rm nixos/nix bash -c 'nix-shell -p nix-info --run "nix-info -m"'
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.24`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.11.0`
 - channels(root): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs

After thinking about that result for a while, I realised the docker image I'm using might be out of date, so I ran docker pull nixos/nix, and I did get a different output after running the command a second time:
$ docker run --rm nixos/nix bash -c 'nix-shell -p nix-info --run "nix-info -m"'
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.24`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.15.0`
 - channels(root): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

nodejs is also pulled from binary cache just fine inside this container also.
I suppose I'm going to have to recompare my derivations with this new nixos/nix image, and I'll also look into how to updating my nix-env on my local machine, as on my system its' 2.3.16, but in the new container its 2.15.0. I don't know if updating this will make a difference, but I'll try it

This does not provide you with nixpkgs version alas. Please try: nix-instantiate --eval -E "(import <nixpkgs> {}).lib.version" rather.

mine:
$ nix-instantiate --eval -E "(import <nixpkgs> {}).lib.version"
"23.05pre476152.2362848adf8"

the nixos/nix docker container:
nix-instantiate --eval -E "(import <nixpkgs> {}).lib.version"

the nixos/nix docker container when I update the channels before running that command:
$ docker run --rm  nixos/nix bash -c 'nix-channel --update && nix-instantiate --eval -E "(import <nixpkgs> {}).lib.version"'
unpacking channels...
"23.05pre476152.2362848adf8"

As you can see, you need to update the channels if you want to have the unstable nixpkgs in the Docker container, otherwise it is just running 22.11 which is a stable release.

I am trying to install<EMAIL_ADDRESS>on my new MBP with<EMAIL_ADDRESS>and it also tries to compile it. I've just waited for an hour and stopped

You meant nixpkgs or nixos @ 23.11, i.e. unstable.

@RaitoBezarius  thanks for a quick answer
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
is it not cached? what should I use instead? Sorry, I am new to nix

This should give you cached Node.js but your problem is not well described enough, please open another issue with more context or drop in the Matrix channel so someone may help you.
In the meantime, I will close this as it seems fixed for OP, feel free to reopen with more information.


Test hangs if element scroll is fractional

Move automation fall to an endless loop, because the target point coordinates will be fractional in this case, and we use integer coordinates for the pointer current position, so they will never be equal.

@AndreyBelym Can you provide a test code please?

It's related to https://isc.devexpress.com/Thread/WorkplaceDetails/T432527, I'll post a regression test and page for the test here.


Adding historical activities via Activity page will corrupt meter history

Only new activities should be added to ensure the timeline is correct. Alternatively, the submission form could be made more sophisticated to handle historical data.

Fixed as of 11/15/2023


Kompilation of LLVM definition fails for K installed with kup

Kompilation of the LLVM target with K installed using kup fails: kompile-kup.txt
/home/ttoth/git/evm-semantics/.build/usr/lib/kevm/blockchain-k-plugin/include/c/crypto.cpp:1:10: fatal error: 'cryptopp/keccak.h' file not found
#include <cryptopp/keccak.h>
         ^~~~~~~~~~~~~~~~~~~
1 error generated.
[Error] Critical: llvm-kompile returned nonzero exit code: 1

On the same system I'm able to kompile the target with K build from source: kompile-source.txt
Nix profile: nix-profile.txt

This is a known issue with kup-installed K, I think - @goodlyrottenapple can probably explain why better than I can, but in general, external dependencies don't work with the Nix-installed version.


BUG: Stale values after using .updateOptions() / .setOptions()

We're running into a lot of issues using dependent queries, and I believe we've tracked it down to the store values not updating immediately after calling .updateOptions() and .setOptions().
I've created a REPL to demonstrate the issue here: https://svelte.dev/repl/458963582d5c4b828b6152d44eb95467
In this example, the query fetches https://jsonplaceholder.typicode.com/todos/${id}, and the response has an id value that matches the one in the request. I have a <select/> element that changes which ID is being queried, and this reactively calls .setOptions()
$: query.setOptions({
  queryFn: getTodo,
  queryKey: keyFactory.todo(value)
})

but in other reactive calls depending on the id and results of this query still show a stale value immediately after setting this
$: {
  if ($query.isSuccess && $query.data && `${$query.data.id}` !== value) alert("invalid") // this should never happen, but it does
}

I've also tried adding enable: false to .setOptions(), which should definitely not show data and .isSuccess, but that, as well as .isError and .isLoading are also stale.
I tried combining these into one reactive block, but still the same issue
$: {
  query.setOptions({
    // enabled: false, // Happens even if query is immediately disabled
    queryFn: getTodo,
    queryKey: keyFactory.todo(value)
  })
  if ($query.data && `${$query.data.id}` !== value) {
    alert(`data.id -> ${$query.data.id} !== ${value} <- value\nqueryKey:${JSON.stringify(keyFactory.todo(value))}\nisSuccess: ${$query.isSuccess}\nisLoading: ${$query.isLoading}`)
  }
}

I thought this might be a Svelte limitation of reactive blocks and/or store updates, but I built a simple test store and can see the updated value immediately after: https://svelte.dev/repl/1a66de513c67498c978eeeb62bebaf57
$: {
  console.log("BEFORE", $mystore)
  mystore.add(parseInt(amt))
  console.log("AFTER", $mystore)
}

Console:
"BEFORE" 0
"AFTER" 1
"BEFORE" 1
"AFTER" 6

At the very least, it that if the query is updated to a queryKey that isn't in the cache, the .data should immediately be undefined and .isSuccess should be false

FWIW, I built the same thing in React using react-query and this issue does not occur https://codesandbox.io/s/staging-framework-bobm69?file=/src/index.js


Audiobookshelf

I think audiobookshelf is potentially useful. I don't really understand d.rymcg instances so I just deleted the instance.yaml that d.rymch.tech create created. And there's possibly other ways to improve this before merging into master.
Also, I apparently had a bunch of commits I forgot about when I pushed to this branch. What's the best way to fix that?

Also, I apparently had a bunch of commits I forgot about when I pushed to this branch. What's the best way to fix that?

You can just push more commits, when this gets merged they will all be "squashed" into one new commit. I'll mark this as a draft PR for now.

Also, I apparently had a bunch of commits I forgot about when I pushed to this branch. What's the best way to fix that?

You can just push more commits, when this gets merged they will all be "squashed" into one new commit. I'll mark this as a draft PR for now.

I don't have any more commits. I think it's ready to go, unless I didn't handle instances well or there's anything else you think should be improved.

OK, I'll check it out today. I notice theres some remnants of an XBS config here xbs/api/settings.json

Yes, those are some of my past commits that I had forgotten about and mistakenly pushed into this branch.

I think that's it. There are some merge->master commits, but it doesn't look like those need un-doing.

I added a review, and then fixed it myself. I added the instance template back in. Even though audiobookshelf supports multiple users, it still contains universal configuration and a 'root' user. So multiple instances would allow, eg. mike and ryan to each own a separate instances with different configs and volumes, but on a shared droplet, where each have separate root users/backups.


Adds initial support to connect to token backend

This PR is another WIP PR adding incremental non-admin feature support; it includes:

Adds MigToken support to the client
Adds token polling
Hooks up the Tokens table to the redux tree and removes fake tokens
Adds "Add Token" support for SAs
Some amount of refactoring where it made sense (ex: moving the token form values into the token types, since it is used in at least 2 places other than the form component itself)

It does not include:

Token edit/delete
OAuth token support (will follow up with this)

I also discovered #917 while implementing this but refrained from fixing it and adding scope creep. I'd like to follow up this PR with a distinct PR to repair this issue as well.
Closes #891
Closes #885

@ibolton336 That's correct. We should use an empty state component inside of table as shown here: https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/empty-state

Added empty state for tokens:

Hey, sorry I didn't look at this sooner. I had originally left out the empty state for tokens because Vince told me to, since we assumed the user would always have at least the one token they logged in with.

Sure @mturley, blame it on the designer who doesn't know anything.  😉  @eriknelson didn't you tell me that users will always have at least one token? That's what I have in my notes because "user can't delete the host cluster token".

Yeah I forgot about that, I don't expect the host token to ever be invalid or to be removable. It's exposed here because we don't have the auto creation of the logged in token implemented yet.

Haha, sorry Vince. I was pretty confident you were right, if that helps 🙃


postPairingsURL - fix controller update

Ensure updating existing controller set up proper permissions.
Attempt to fix https://github.com/HomeSpan/HomeSpan/issues/414 - works for me, I'm not 100% sure if that's the correct way of doing it.

This portion of the code was refactored to address the error.  Available now in the dev branch and will be released as part of the next HoneSpan update (version 1.7.0) in about a week.


manage_firewall is set to 'false' by default

As per documentation it says "manage_firewall: Wheter you want to manage the firewall. If true (Which is default), iptables will be configured to allow communications to zabbix ports."
However 'manage_firewall' is set to 'false' in params.pp file. I had to manually set it to 'true' to get it working. Either documentation should be updated or params.pp should be modified so that manage_firewall is default to 'true.
Thanks

does it fail if iptables is not active? in this case it should be false,
otherwise its safe to set to true
2015-05-07 21:05 GMT+02:00 mimra<EMAIL_ADDRESS>
As per documentation it says "manage_firewall: Wheter you want to manage
the firewall. If true (Which is default), iptables will be configured to
allow communications to zabbix ports."
However 'manage_firewall' is set to 'false' in params.pp file. I had to
manually set it to 'true' to get it working. Either documentation should be
updated or params.pp should be modified so that manage_firewall is default
to 'true.
Thanks
—
Reply to this email directly or view it on GitHub
https://github.com/dj-wasabi/puppet-zabbix/issues/86.

Hi,
The documentation is updated just a few minutes ago. It should not be enabled at default. It's an user decision for enabling the iptables config, not "my" decision. :-)
Kind regards,
Werner


User can't update Avatar / Banner alone

When user tried to update their Banner without setting a new avatar, server will return 500 and nothing happens.

Fixed in https://github.com/dalibor-osu/lovelive.cz/pull/66

Fixed in https://github.com/dalibor-osu/lovelive.cz/pull/66


Create student.ccc.edu

thx

@gcmitchellstudentcccedu This domain is blacklisted because the college allows to register an email address there even if you are not a student of the college. If you are the student of this college, please apply with official document ("OFFICIAL DOCUMENT" tab at https://www.jetbrains.com/shop/eform/students).


Auto readme isn't working with Node16

Hi, recently github updated its configuration for actions from nodejs 12 to 16, but, the project now isn't working
Here a picture with the prompt from actions.

finally when the actions are running i get this error

Thanks for reminding me! I released v2.

It won't commit if nothing changed.
You went to 0 commits here, previous to the update - not sure why. Check/regenerate the token.
https://github.com/M8-Babbage/M8-Babbage/commit/0fc9f409787ef2efa4653b6fa4cbd6e23d755d1a

Ok, I found the problem, my profile was private, therefore the confirmations are not available, thanks for your help!


Added rounding for instructor rating in course popup

Description
Added checking to see whether it was a single digit integer, if so, it wouldn't add two extra zeroes like currently. Though if it was a long decimal, added a fixed rounding of two.
Steps to verify/test this change:

Used same method of rounding from other parts of the code
Made sure that the type and variable worked with it

Final Checks:

[ ] Verify successful deployment

(optional)

[ ] Write tests
[ ] Write documentation

Issues

Closes #
#371

Sorry, do you have feedback on what I did wrong?

Sorry, do you have feedback on what I did wrong?

No, you're changes look good to me! I'm not sure why it failed to deploy, that's something on our end I'll have to look into.


Improve instrumentation

Instrumentation so far is pretty sparse:

Make compaction duration metric a summary (no generally applicable histogram buckets possible)
Fsync duration of the WAL
WAL corruptions detected

There's probably a lot more. Though a lot of performance metrics around querying aren't really possible due to lazy evaluation.

Can we have a histogram of series per block? This would allow users to see whether the blocks are well distributed or there is massive variance in their sizes.
Also a measure of count of all stored series (in "live blocks") would be fantastic: it would allow comparisons with P1. Additionally, the number of series in WAL-stage and non-commited to blocks would also be incredibly useful.

Instrumentation is pretty good now. Anything related to histograms/summaries around blocks doesn't really work though. The cardinality of observations is so low that the resulting graphs look practically broken.

@fabxc can you think of any other metric that is needed right now?
Otherwise maybe can close this one  and open new issues for any new metric that would be useful to add.


GRL 1.1 TH reports "Contract class not implemented -OpenThreadNo module named commissioner" using current THCI and DeviceInputFields.xml

Describe the bug A clear and concise description of what the bug is.
Console/log output If applicable, add console/log output to help explain your problem.
Thread V1.1 Test Harness Release 2.2.2
Python Version:  2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:22:17) [MSC v.1500 32 bit (Intel)]
ARM True
Kirale True
NXP True
OTFF True
OTN True
OTS True
Error: THCI cannot be included OpenThread has error or Does not implement Contract class(iThci)
Log -->   [Contract class not implemented -OpenThreadNo module named commissioner]

Error: THCI cannot be included OpenThread_BR has error or Does not implement Contract class(iThci)
Log -->   [Contract class not implemented -OpenThread_BRNo module named commissioner]

Git commit id - 95c5cb793
Network topology - GRL 1.1

Expected behavior A clear and concise description of what you expected to happen.

I expected the THCI to load into GRL without error but it cannot locate this commissioner module.  I attempted to follow the steps in the readme, however it looks like that file is not updated since it contains no references to OpenThread_BR.py.  It would be nice to have up to date instructions for this installation if possible!

Thanks for reporting this bug. commissioner library exists only in Thread Dev Harness 1.2.
Will file a PR to fix.

Thank you for the fix!  This new THCI is loading up just fine in the 1.1 TH.


AI Doesn't make entities swim upwards.

As you can see in the attached image, the AI doesn't seem to make the latex swim upwards, which leads to this.

this was already covered by a report i made, they seem to not be able to path-find well to players outside of the water

This was already fixed for 0.11.


Cyhy feeds

I don't think the MOE bucket is created in Terraform.  Is there a reason why we don't want that bucket under Terraform's control?

This code as it is now cannot be deployed to more than one workspace, at least in the same region.  The reason is that the MOE read and write user names will conflict.
@KyleEvers are you OK with me appending the workspace name to those user names?


Add ObjectWrapper test

Supplement the missing unit test cases for ObjectWrapper.
The already exists test class BeanWrapperTest is to test MetaObject, but not BeanWrapper.

coverage: 87.17% (+0.09%) from 87.077%
when pulling 851b79803f0d2d0a8f49cd16db0237ca29faa9b7 on mawen12:feature-objectwrapper-test
into 2e0927e91572ffe15a1de17c7aa08cc4f84f16e3 on mybatis:master.


[Visual Studio Code Recent Projects] not working with vscode 1.68.1

Extension – Visual Studio Code Recent Projects
Author: @thomaspaulmann

Description
Steps To Reproduce

upgrade vscode to 1.68.1
try to use vscode recent projects raycast command

The current behavior
nothing loads, raycast just shows loading indicator line
https://user-images.githubusercontent.com/2199845/175325716-92005212-3519-4369-9145-81c7505605d8.mov
The expected behavior
should see list of my recently opened projects
Raycast version
Version: 1.36.1

my version says last updated 4 weeks ago. Opening the store doesn't visually do anything (maybe it tries update in background?)
I also just uninstalled it and reinstalled the ext and still seeing same result :(

Not sure what changed but it's working now

Oh okay... Weird indeed but happy that it get resolved. Let me know if something causes it again.


Should the Trainer attributes be protected?

❓ Why are the Trainer attributes not protected?
Sorry if this was already discussed before, but I was wondering.
Currently, the following code works and doesn't complain:
trainer = Trainer()
trainer.checkpoint_callback = 'bad manners'

Is there a reason why attributes like these are not protected? For example this
class Trainer:
    def __init__(self):
        self._checkpoint_callback = ...

    @property
    def checkpoint_callback:
        return self._checkpoint_callback

would make the attribute read only and prevent anyone from accidentally changing the state of The trainer.
Is the callback system possibly the reason for this, so that the callback method has full access to trainer variables? If so, I feel a property + setter approach would still be better.

I agree that some shall be protected as well as some methods which are not meant to be used by user shall be protected too...

This is marked as wontfix so it probably won't be done, but for the record that would be a very unusual behavior for Python, “we are all consenting adults here” and I don't think that a lib going out of its way to do that kind of thing would be a good thing.

totally agree :)
the bot added this wontfix label and wanted to close the issue due to inactivity.

This is marked as wontfix so it probably won't be done

sorry for the confusion, it was an automatic bot marking non-active issues...
Agree with @awaelchli we ll do it, just did not have time yet :rabbit:
@Evpok mind take it over and draft a PR with these changes?

Well, I was trying to argue that it should not be done, since it adds unnecessary complexity and makes it harder to monkey patch if needed :-)

the point of protected is to clearly separate what is the recommended API and what is internal staff so you can still use it but to be aware that you are using something that is meant to be just internal PL use and you need to know how to use it correctly... so it does not add any complexity, all functions/classes stay as they are just minor rename with _

Right, that makes sense, sorry for being dense :-)


\token_if_..._register

Those conditionals are broken if escapechar is not 92 (standard value). Namely, these tests will always return false (I think) if the escapechar is different from its value at definition time.
Also, \token_if_count_register should take care of \count and \countdef, and the same is true for other registers.
We may also give a \token_if_int, which recognizes both \count123 and \mathchar"123, since both are used in l3int.
(I'm logging this issue mostly for myself. I'll think of a fix.)

This is fixed by revision 3216.


Support context callback

Passes a context variable to kernels, making it necessary for kernels
to execute a context.done() or context.fail() upon completion.
This also means that functions passed in a waterfall/flow must also
expect a callback. This makes the code more Node-friendly in some ways.
The map and tee functions are now asynchronous as well, using
event emitters and a collector to retrieve results.
Signed-off-by: Eric Windisch<EMAIL_ADDRESS>

@tizzo this is the WIP PR for async pipes. I'm behind on writing tests, having those will make me more comfortable with the merge. Thanks for your feedback last night!

The go version is ugly as sin, but it's working and passing tests.

Closes #60


Dialog open prop not respected

Current behavior
Based on my understanding, when using the code snippet:
const dialogStore = useDialogStore({ open: true });

the dialog should remain 'open' regardless of any actions like clicking outside or pressing the escape key.
However, it seems that this behavior is currently broken as the dialog is closing.
Important:
This might be related to another bug I'm noticing in ComboboxPopover where the alwaysVisible prop is not respected.
Steps to reproduce the bug

Open sandbox: https://codesandbox.io/p/sandbox/naughty-bush-zgs3qh
Click on the white background
Notice how the dialog closes

Expected behavior
The dialog should stay open when you either

Click outside of it
Hit the escape key

Workaround
I'm resorting to doing this for now
<Dialog
  hideOnInteractOutside={false}
  hideOnEscape={false}
>

Alternatively:
<Dialog open>

Thanks for the report. This issue might be connected to the new feature allowing Dialog to receive its own open prop, which could potentially conflict with the open state from the external store.
Could you provide more specifics about your use case? This would assist us in creating an example and ensuring this doesn't reoccur in the future.

A common use case for this is dialogs that require specific user actions. Users should not be able to manually close them; instead, we want to close them programmatically, for example, after the user has taken some action.


#1075 Add travis ubuntu 16.04 build

Description
Add travis builds on the latest ubuntu LTS version (16.04) in addition to 14.04 (Bluemix support).
Travis does not have a ubuntu 16.04 environment, so we need to tweak our build scripts to run on docker using a ubuntu 16.04 image.
Motivation and Context
#1075
How Has This Been Tested?

Checklist:

[ ] I have submitted a CLA form
[ ] If applicable, I have updated the documentation accordingly.
[ ] If applicable, I have added tests to cover my changes.

Codecov Report

Merging #1084 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #1084   +/-   ##
======================================
  Coverage    89.9%   89.9%
======================================
  Files          35      35
  Lines        1714    1714
======================================
  Hits         1541    1541
  Misses        173     173

Flag
Coverage Δ

#Kitura
89.9% <ø> (ø)
:arrow_up:

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 678999c...6b2a3f8. Read the comment docs.


Terminology: Change 'data' to 'attributes'

'Data' is fairly ambiguous; 'attributes' better describes these objects.

Although this is a fundamental change to our vocabulary (see #49), in the codebase it is likely just a comprehensive find and replace of data -> attribute. This needs to happen everywhere - in class names, property names, documentation, tests, etc.


Support dark/light mode in Storybook

Feature Suggestion

Make it possible to toggle dark/light mode inside Storybook. This will allow for easier verification that components behave correctly in both themes.
Possible Implementation

https://medium.com/encode/setting-up-storybook-with-material-ui-and-styled-components-5bdacb6db866
Context

Thanks for creating the issue @stefanalund and the medium article. Let me start the implementation.
This storybook documentation is helpful too https://storybook.js.org/docs/configurations/theming/

Thanks for looking into this @OrkoHunter -- I assigned you to the Issue.

Thanks @stefanalund !


Optional object fields always created

Models containing fields of a custom class type seem to always be created when retrieving a document from the collection, even if said field is optional.
For example, the model:
class Thing extends Typegoose {
    @prop() text: string;
}

class Container extends Typegoose {
    @prop() numeric: number;
    @prop() custom?: Thing;
}

The collection:
[ { numeric: 1 } ] // _id omitted for brevity

If you query and log the result to the console, it logs the expected value
Collection.findOne({ numeric: 1 }).then(r => console.log(r));

logs
{ numeric: 1 } // _id omitted for brevity

But you can somehow still access the non-existent 'custom' field and it will return an empty object
Collection.findOne({ numeric: 1 }).then(r => console.log(r['bonus']));

logs
{ }

whereas it should be undefined since it isn't defined in the document.
I'm not exactly sure that this is Typegoose's fault, but I don't think this should happen using just Mongoose, but I haven't tried. 😕

Hi @Pikachews
I tested your issue and it is true that it prints an empty Object, so I created a native mongoose test to see how it works there.
my mongoose schema:
  nested: {
    value: String,
  },
  numeric: Number,
});

export const mongooseModel = mongoose.model('Test', testSchema);

my test code:
      numeric: 1,
    });

    console.log(JSON.stringify(nativeMongoose, null, 2));
    console.log(nativeMongoose['nested']);

    const foundNative = await Test.findOne({
      numeric: 1,
    });

    console.log(JSON.stringify(foundNative, null, 2));
    console.log(foundNative['nested']);

That printed out the following:
{
  "__v": 0,
  "numeric": 1,
  "_id": "59c2287fe89e526d3f9ccb07"
}
{}
{
  "_id": "59c2287fe89e526d3f9ccb07",
  "numeric": 1,
  "__v": 0
}
{}

So the native mongoose implementation prints nested objects too. We don't want to differ from their functionality, even if it is not completely logical so I am closing this issue.
Thanks for using Typegoose and reporting your issues.
Cheers,
Daniel


Fails during generation with "undefined method `to_ios'"

I've got asciidoctor-epub3 crashing during epub generation on a document that I'm working on. I've been able to reproduce the same crash using the following minimal test case.
$ cat bug.adoc
= Asciidoctor EPUB3: Sample Book
Author Name
v1.0, 2014-04-15

== Hello World

How do you do
$
$ asciidoctor-epub3 bug.adoc
undefined method `to_ios' for #<Asciidoctor::Epub3::Packager:0x9d68f68>
Use --trace for backtrace

Full trace
$ asciidoctor-epub3 --trace bug.adoc
/var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:288:in `postprocess_xhtml': undefined method `to_ios' for #<Asciidoctor::Epub3::Packager:0x8770044> (NoMethodError)
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:235:in `block (3 levels) in add_content'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:233:in `each'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:233:in `each_with_index'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:233:in `block (2 levels) in add_content'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/resource_builder.rb:40:in `instance_eval'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/resource_builder.rb:40:in `block in ordered'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/package.rb:166:in `ordered'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/book.rb:205:in `ordered'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/resource_builder.rb:39:in `ordered'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:230:in `block in add_content'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/resource_builder.rb:33:in `instance_eval'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/resource_builder.rb:33:in `initialize'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/builder.rb:292:in `new'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/builder.rb:292:in `resources'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:225:in `add_content'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:407:in `block in package'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/builder.rb:185:in `instance_eval'
    from /var/lib/gems/1.9.1/gems/gepub-<IP_ADDRESS>/lib/gepub/builder.rb:185:in `initialize'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:325:in `new'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/packager.rb:325:in `package'
    from /var/lib/gems/1.9.1/gems/asciidoctor-epub3-1.0.0.dev/lib/asciidoctor-epub3/converter.rb:36:in `write'
    from /var/lib/gems/1.9.1/gems/asciidoctor-1.5.0/lib/asciidoctor/document.rb:1033:in `write'

It isn't really clear to me what is triggering this bug. Strangely enough, in my actual document, the bug is triggered in only one scenario. I've got a master.adoc within which I include a.adoc, b.adoc, etc. Running asciidoctor-epub3 on master.adoc works fine. But if I don't include the files and instead concatenate master.adoc, a.adoc, b.adoc and feed the resulting file to asciidoctor-epub3, then this crash happens.

I'm guessing that in the initialize function in packager.rb @spine is getting assigned to a type other than string (possibly an empty array?), if no "spine" is provided
  def initialize spine_doc, spine, format = :epub3, options = {}
    @document = spine_doc
    @spine = spine || []
    @format = format
  end

Yes, but the problem goes much deeper than that because the logic in the packager simply doesn't know how to proceed when there is no spine atm. What needs to happen is a spine needs to be created automatically in this case.

This is a duplicate of #47. Until then, you have to structure your document as documented in the README. See https://github.com/asciidoctor/asciidoctor-epub3#structuring-your-manuscript.

This bug is 3 years old now. Any chance of getting it resolved?

This is not a bug, it's just how this converter is designed. You have to adhere to the structure described in the README.
(Yes, I'm still considering improving that design to make it more flexible. I just don't have time right now.)

Since this is covered by #47, I'm closing this one so we can centralize the conversation about the improvement.


feat(help)!: Improve the looks of help command

Summary
Refactors DefaultHelpCommand to look less outdated and ugly.
You could consider this a breaking change due to DefaultHelpCommand loosing some functionality. Though, DefaultHelpCommand should not be subclassed to begin with.
An image of how everything looks is in the comments.
resolves #690
Checklist

[x] If code changes were made then they have been tested.

[x] I have updated the documentation to reflect the changes.
[x] I have run task pyright and fixed the relevant issues.

[x] This PR fixes an issue.
[x] This PR adds something new (e.g. new method or parameters).
[x] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, ...)

Main help

Cog help

Group in cog

Command in cog

Group outside cog

Command outside cog

Command chaining

Looks good

Have you considered the possibility of subclassing a help command to add an "EmbedHelpCommand" for example, rather than overwriting the existing default?
That way it would be less of a breaking change since you could always choose to revert to the non-embed version.

Have you considered the possibility of subclassing a help command to add an "EmbedHelpCommand" for example, rather than overwriting the existing default?
That way it would be less of a breaking change since you could always choose to revert to the non-embed version.

The point of this PR is to improve the existing one and not make another default one. Personally, I think the current DefaultHelpCommand is very outdated and it shows.
And in terms of breaking, as I have said in the summary, I don't know how to really evalute of the "breaking" status of that PR, because HelpCommand is supposed to be subclassed, not DefaultHelpCommand. Therefor I doubt that this is much breaking in a user-wide sense.

While HelpCommand or minimalhelpcommand is more often subclassed, people do use defaulthelpcommand and it is documented. Doing a search turns up some results, mostly within jishaku it seems. I have not tested it yet, but it may be a good idea to test some existing use cases to make sure it's not going to immediately break a lot of bots.
https://github.com/search?q="Defaulthelpcommand"&type=code

I have not tested it yet, [...]

@EmreTech as well as myself tested that and it should be golden.

test some existing use cases to make sure it's not going to immediately break a lot of bots.

What I also could do is, still override DefaultHelpCommand but as an addition add the previous DefaultHelpCommand as something like LegacyHelpCommand or something.
This way, the old help commands gets replaced but would be a pretty easy fix but just changing the class.

I implemented a LegacyHelpCommand class which is basically the old ´DefaultHelpCommand´, that should be easy enough for devs that subclass the DefaultHelpCommand to fix, it's a simple class change.

The current implementation of HelpCommand is meant to be customized by the user as the lib wants the user to be given the choice to decide the text, colors, and formatting. Help command preferences can be different for everyone and some designs may be better suited for different bots.
Currently there are 2 built-in choices for help commands (DefaultHelpCommand and MinimalHelpCommand) and it is easy to select the other in the bot's constructor (eg. Bot(..., help_command=MinimalHelpCommand())
I think a collection of pre-built custom HelpCommands could be useful, though. Maybe in /examples or a third-party library that HelpCommands can be imported from.
As of now, I think sticking to Discord.py's decision may be best (https://github.com/Rapptz/discord.py/issues/5081).

In my opinion, the DefaultHelpCommand was never really intended to support a lot of customization, hence it being the default help command. Makes sense, why would the library do your work on being crazy customiziable?
Moreover, I don't agree with you on the meant to be customized part. The things you are allowed to customize are not really big things.

send to DM instead of channel - not really customization but just a simple switch
indent - that is bare customization at max
paginator - that is indeed customization
width - that falls off due to the embed

Also, you can change the text and heading with my implementation, too.
Just by the looks of the command alone, you are very limited in what you can do. I personally don't think much people would spent a lot of time customizing DefaultHelpCommand, especially just be the not-great look of it alone, just does not look proper and / or not something that got the littliest amount of love in the development process of a bot.
Just like:
Would you really spent much money customizing a car which has 4 tires and a rusty body? Probably not.
I also wonder why you first suggest implementing some backwards-compatability, and 8 days after I did that suggesting something different.
What made you come to this different conclusion now? Genuinely curious.

I'm still thinking about the best way to go about this. I personally don't think this change is necessary as the current help command system is the way it's been for years and it's working perfectly.
My original thought was that instead of changing the default, you could make a class that people could optionally use instead of the default. I did suggest it could be a default that could be reverted, but after thinking about it longer, I think changing the help command from the current default should be an optional opt-in.
I recently had the idea recently of creating a library of many custom help commands people can import to use in their project. Along the lines of that I remembered this PR and thought that might be a good alternative solution so I came back here to suggest it. If others think it's a good idea, we could go forward with it and I'd be happy to have collaboration on that.
I'm still open to suggestions on how your idea could best be implemented, for example, whether custom help commands like the embed version should be added in nextcord.ext.commands.help similar to MinimalHelpCommand or whether it should be a separate pypi download (I'm leaning toward the latter).

Have you considered the possibility of subclassing a help command to add an "EmbedHelpCommand" for example, rather than overwriting the existing default?
That way it would be less of a breaking change since you could always choose to revert to the non-embed version.

Coming back on this, this seems like a nice solution, especially with the context of this dicussion here.
I can implement the EmbedHelpCommand and let DefaultHelpCommand as it is right now.
With it just being a new class, that would be a nice-looking help command which you can opt-in if you want to

I like the idea of keeping the existing help command, with the idea of this moving to a separate ext with other help commands as was partially discussed on discord under the nextcord repo.


en: add 2 faqs and update 1 faq

What is changed, added, or deleted? (Required)
Add 2 FAQs and update 1 FAQ.

Which DM version(s) do your changes apply to? (Required)

[x] master (the latest development version, including v3.0 changes)
[x] v2.0 (TiDB DM 2.0 versions)
[x] v1.0 (TiDB DM 1.0 versions)

What is the related PR or file link(s)?

This PR is translated from: https://github.com/pingcap/docs-dm/pull/523
Other reference link(s):

Do your changes match any of the following descriptions?

[ ] Delete files
[ ] Change aliases
[ ] Need modification after applied to another branch
[ ] Might cause conflicts after applied to another branch

LGTM

LGTM


Show current issue without enabling voting

To show issue text.

Just to add more context;
This is to show the issue text without opening the voting. The voting can be opened at a later state, but it makes it possible for users to see the issue text before voting starts.

Solved in 22dc0a2 and bcf3ab9


wrapper.setChecked(true) sets radioButton.selected = true not radioButton.checked = true

Version
1.3.0
Reproduction link
github.com
Steps to reproduce
Switch to node version 14.15.1 -> run npm i -> run npm test
What is expected?
tests should pass
What is actually happening?
tests are failing

https://github.com/vuejs/vue-test-utils/blob/106070827131ce0319108b5f7ca8236829384878/packages/test-utils/src/wrapper.js#L600
should set " this.element.checked = true" not  "this.element.selected = true"

const radioInput = wrapper.find('input[type="radio"]');
await radioInput.setChecked();
expect(radioInput.element.checked).toBeTruthy();

this test should be pass, instead of failling


BAEL-3224 - Checking if Two Java Dates are On the Same Day

Review comments fixed. New branch as suggested.

retest


SQL-140 Keycloak Demo

Set up a keycloak demo for ongoing OIDC development.
To create and start the Keycloak demo environment on port 8081:
make keycloak-demo

To start an ephemeral instance of SQL LRS configured to use it for OIDC authentication:
make ephemeral-oidc

The lrsql_testing branch of re-oidc can be used to verify that authentication and LRS communication is working.

I also noticed that you added a keycloak dir at the top level. Is there a reason for that instead of locating that dir within, say, dev-resources?

It's by convention, matches our other projects. I don't mind moving it, should work just as well.


Symlink uv itself into venv

The following workflow seems to have no uv counterpart:
python3 -m venv /path/to/venv
/path/to/venv/bin/pip install somepkg
/path/to/venv/bin/python -m somepkg

It would be nice to be able to run
uv venv /path/to/venv
/path/to/venv/bin/uv pip install somepkg
/path/to/venv/bin/python -m somepkg

where none of the advanced features of uv are required, only its speed.

You don’t need uv to be in the environment in order to manipulate the environment.

The main rationale for this request is simply the principle of least surprise. If pip can do something, then uv pip should be able to do the exact same thing.
To be specific, I suggest the following:

that an executable called uv be put into all newly created virtualenvs
that if called, it should discover the virtualenv in which it’s located and only affect that virtualenv
that uv executables created by any method other than uv venv, such as pipx install uv, do not do this, because otherwise, for example, uv from pipx would try to affect the virtualenv into which pipx installed it

How this compares to current behavior:

it will be possible to execute /path/to/venv/bin/uv, currently that’s not possible
given PATH=/path/to/venv/bin:$PATH, uv invocations will affect that venv, but the current behavior is also exactly the same as uv discovers virtualenvs from $PATH

How this can bite the user in the behind:

if a symlink to uv is put into a virtualenv and later the uv binary moves to a different place which is still on $PATH, in which case the old way would work but the new one won’t. The same would happen with the python interpreter itself though, so virtualenv users are already aware of such a possibility.

Alternatives:

put an executable called pip (or uvpip or something) that works exactly like normal pip would, including virtualenv discovery from the directory containing it, but that would call uv pip behind the scenes. This would enable the use case I mentioned in the issue (specifically, what I wanted was to install spacy and ipython to run some ad hoc stats on a piece of text, I had no interest in creating a pyproject.toml for a throwaway script).

Related concerns:

on Windows there may be other reasons to have uv within the venv (see #3876)
if uv reaches widespread adoption and distributions such as Debian, known for conservativeness with new versions of stuff, start packaging it, there may be need for system uv to download and install a more recent version of uv into a newly created venv

@charliermarsh One binary you definitely don’t need in the environment to make use of it is python, yet it’s there.

I'm sorry, but I'm not really convinced this is worth the additional complexity.


Update k8s test image, sdk now blocks on receive

Proposed Changes

Minor cleanup of the test image for running k8s e2e test, the sdk blocks when receive is called.

Release Note

NONE

/lgtm


Add showIntercomWindow and fix code style

lg2m, I need to add prettier add a hook to lint the project on commit.

Sounds good, I need this library so I'll probably open a few more PRs in the near future. Maybe also consider renaming the project "next-intercom" to match most Next.js plugins (next-connect, next-env, etc.), it might make it a bit easier to find.
Thanks so much for the awesome lib!

lg2m, I need to add prettier add a hook to lint the project on commit.

Sounds good, I need this library so I'll probably open a few more PRs in the near future. Maybe also consider renaming the project "next-intercom" to match most Next.js plugins (next-connect, next-env, etc.), it might make it a bit easier to find.
Thanks so much for the awesome lib!

Your welcome, and great idea on changing the project name. Updated it to next-intercom to align better.


Hot reload with blazor ?

We will have auto-rebuild support initially. True hot reload is harder and we're still discussing how it can be enabled. This is tracked by https://github.com/aspnet/AspNetCore/issues/5456, so I'm going to go ahead and close this one.
For future reference, all Blazor work is now tracked in the https://github.com/aspnet/aspnetcore repo.


Failing to compile torchvision C++ API from source (>C++14 compiler required, which is installed)

🐛 Bug
I have installed PyTorch version 1.8.0 from source and am now attempting to install the C++ API to torchvision 0.9.0 from source.
When making torchvision's C++ API I am getting an error that I need to use a C++14 or later compatible compiler (I am using gcc 9.3.0 which supports C++14):
root@pc:/resources/vision/build# make VERBOSE=1 -j4
...
...
...
[ 71%] Building CXX object CMakeFiles/torchvision.dir/torchvision/csrc/ops/cpu/roi_pool_kernel.cpp.o
/usr/bin/c++  -DWITH_CUDA -D__CUDA_NO_HALF_OPERATORS__ -Dtorchvision_EXPORTS -I/resources/vision/torchvision/csrc -isystem /usr/local/lib/python3.8/dist-packages/torch/include -isystem /usr/local/lib/python3.8/dist-packages/torch/include/torch/csrc/api/include -isystem /usr/local/cuda/include -isystem /usr/include/python3.8  -fPIC   -D_GLIBCXX_USE_CXX11_ABI=1 -std=gnu++14 -o CMakeFiles/torchvision.dir/torchvision/csrc/ops/cpu/roi_pool_kernel.cpp.o -c /resources/vision/torchvision/csrc/ops/cpu/roi_pool_kernel.cpp
[ 73%] Building CUDA object CMakeFiles/torchvision.dir/torchvision/csrc/ops/cuda/deform_conv2d_kernel.cu.o
/usr/local/cuda/bin/nvcc  -DWITH_CUDA -D__CUDA_NO_HALF_OPERATORS__ -Dtorchvision_EXPORTS -I/resources/vision/torchvision/csrc -isystem=/usr/local/lib/python3.8/dist-packages/torch/include -isystem=/usr/local/lib/python3.8/dist-packages/torch/include/torch/csrc/api/include -isystem=/usr/include/python3.8  --expt-relaxed-constexpr -Xcompiler=-fPIC   -D_GLIBCXX_USE_CXX11_ABI=1 -std=c++11 -x cu -c /resources/vision/torchvision/csrc/ops/cuda/deform_conv2d_kernel.cu -o CMakeFiles/torchvision.dir/torchvision/csrc/ops/cuda/deform_conv2d_kernel.cu.o
In file included from /resources/vision/torchvision/csrc/ops/cuda/deform_conv2d_kernel.cu:69:
/usr/local/lib/python3.8/dist-packages/torch/include/ATen/ATen.h:4:2: error: #error C++14 or later compatible compiler is required to use ATen.
    4 | #error C++14 or later compatible compiler is required to use ATen.
      |  ^~~~~
In file included from /usr/local/lib/python3.8/dist-packages/torch/include/c10/util/ArrayRef.h:19,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/c10/core/DispatchKey.h:7,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/c10/core/Backend.h:4,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/c10/core/Layout.h:3,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/core/TensorBody.h:4,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/Tensor.h:3,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/Context.h:4,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/ATen.h:9,
                 from /resources/vision/torchvision/csrc/ops/cuda/deform_conv2d_kernel.cu:69:
/usr/local/lib/python3.8/dist-packages/torch/include/c10/util/C++17.h:24:2: error: #error You need C++14 to compile PyTorch
   24 | #error You need C++14 to compile PyTorch
      |  ^~~~~
[ 75%] Building CUDA object CMakeFiles/torchvision.dir/torchvision/csrc/ops/cuda/nms_kernel.cu.o
/usr/local/cuda/bin/nvcc  -DWITH_CUDA -D__CUDA_NO_HALF_OPERATORS__ -Dtorchvision_EXPORTS -I/resources/vision/torchvision/csrc -isystem=/usr/local/lib/python3.8/dist-packages/torch/include -isystem=/usr/local/lib/python3.8/dist-packages/torch/include/torch/csrc/api/include -isystem=/usr/include/python3.8  --expt-relaxed-constexpr -Xcompiler=-fPIC   -D_GLIBCXX_USE_CXX11_ABI=1 -std=c++11 -x cu -c /resources/vision/torchvision/csrc/ops/cuda/nms_kernel.cu -o CMakeFiles/torchvision.dir/torchvision/csrc/ops/cuda/nms_kernel.cu.o
In file included from /resources/vision/torchvision/csrc/ops/cuda/nms_kernel.cu:1:
/usr/local/lib/python3.8/dist-packages/torch/include/ATen/ATen.h:4:2: error: #error C++14 or later compatible compiler is required to use ATen.
    4 | #error C++14 or later compatible compiler is required to use ATen.
      |  ^~~~~

I think the places of interest are the following:

[ 71%] Building CXX object CMakeFiles/torchvision.dir/torchvision/csrc/ops/cpu/roi_pool_kernel.cpp.o

Uses the flag -std=gnu++14

[ 75%] Building CUDA object CMakeFiles/torchvision.dir/torchvision/csrc/ops/cuda/nms_kernel.cu.o

Uses the flag -std=c++11

It seems like all of the CPU builds use the C++14 flag and the CUDA builds (incorrectly) use the C++11 flag.
Can I point this to CMAKE_CUDA_FLAGS being set in vision/CMakeLists.txt? It looks like CUDA_FLAGS contains the flag -std=c++11 as shown in vision/build/CMakeFiles/torchvision.dir/flags.make:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.16

# compile CUDA with /usr/local/cuda/bin/nvcc
# compile CXX with /usr/bin/c++
CUDA_FLAGS =  --expt-relaxed-constexpr -Xcompiler=-fPIC   -D_GLIBCXX_USE_CXX11_ABI=1 -std=c++11

Any idea where this is coming from? How it's getting set? And how to change it so that it is set to -std=gnu++14 or similar? Is it coming from my PyTorch install?
To Reproduce
Steps to reproduce the behavior:
git clone https://github.com/pytorch/vision.git
cd vision
git checkout v0.9.0
mkdir build && cd build
cmake -DTorch_DIR=/usr/local/lib/python3.8/dist-packages/torch/share/cmake/Torch/ -DWITH_CUDA=on ..

root@pc:/resources/vision/build# cmake -DTorch_DIR=/usr/local/lib/python3.8/dist-packages/torch/share/cmake/Torch/ -DWITH_CUDA=on ..
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The CUDA compiler identification is NVIDIA 11.2.67
-- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc
-- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc -- works
-- Detecting CUDA compiler ABI info
-- Detecting CUDA compiler ABI info - done
-- Found Python3: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found version "3.8") found components: Development
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Caffe2: Found protobuf with new-style protobuf targets.

In file included from /usr/local/lib/python3.8/dist-packages/torch/include/c10/util/ArrayRef.h:19,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/c10/core/DispatchKey.h:7,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/c10/core/Backend.h:4,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/c10/core/Layout.h:3,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/core/TensorBody.h:4,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/Tensor.h:3,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/Context.h:4,
                 from /usr/local/lib/python3.8/dist-packages/torch/include/ATen/ATen.h:9,
                 from /resources/vision/torchvision/csrc/ops/cuda/nms_kernel.cu:1:
/usr/local/lib/python3.8/dist-packages/torch/include/c10/util/C++17.h:24:2: error: #error You need C++14 to compile PyTorch
   24 | #error You need C++14 to compile PyTorch
      |  ^~~~~
make[2]: *** [CMakeFiles/torchvision.dir/build.make:531: CMakeFiles/torchvision.dir/torchvision/csrc/ops/cuda/nms_kernel.cu.o] Error 1
make[2]: Leaving directory '/resources/vision/build'
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/torchvision.dir/all] Error 2
make[1]: Leaving directory '/resources/vision/build'
make: *** [Makefile:130: all] Error 2

Expected behavior
The make (build) completes without error.
Environment
Click to display environment

root@pc:~# python3 -m torch.utils.collect_env
Collecting environment information...
PyTorch version: 1.8.0a0+56b43f4
Is debug build: False
CUDA used to build PyTorch: 11.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.1 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.16.3

Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration:
GPU 0: GeForce GTX 1080
GPU 1: GeForce GTX 1080
GPU 2: GeForce GTX 1080

Nvidia driver version: 460.84
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.1.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.1.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.1.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.1.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.1.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.1.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.1.0
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.21.0
[pip3] pytorch-lightning==1.3.8
[pip3] torch==1.8.0a0+56b43f4
[pip3] torchmetrics==0.4.1
[pip3] torchvision==0.9.0a0+01dfa8e
[conda] Could not collect

PyTorch / torchvision Version (e.g., 1.0 / 0.4.0): 1.8.0 / 0.9.0
OS (e.g., Linux): Ubuntu 20.04
How you installed PyTorch / torchvision (conda, pip, source): source / source
Build command you used (if compiling from source): Listed above
Python version: 3.8
CUDA/cuDNN version: 11.2
GPU models and configuration: 3x GeForce GTX 1080

Additional context
The commands I used to build PyTorch:
git clone https://github.com/pytorch/pytorch.git
cd pytorch
git checkout v1.8.0
git submodule sync
git submodule update --init --recursive
python3 setup.py build -j4 --cmake-only
cd build
cmake -DBUILD_CUSTOM_PROTOBUF=0 ..
cmake --build . -j4 --target install
cd ..
python3 setup.py install
Additionally,
python maps to Python 2.7.18
python3 maps to Python 3.8.10
Lastly, I do have a Dockerfile that I am using... but it builds cuDNN, PyTorch, openCV, and torchvision from source... it's about 20GB and takes a few hours to build.

Looks to be similar to https://github.com/pytorch/vision/issues/2470 as they both fail at the same step in the build process.

Update: I was able to successfully compile by manually changing the CUDA_FLAGS variable (removing the -std=c++11) in flags.make:
flags.make before:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.16

# compile CUDA with /usr/local/cuda/bin/nvcc
# compile CXX with /usr/bin/c++
CUDA_FLAGS =  --expt-relaxed-constexpr -Xcompiler=-fPIC   -D_GLIBCXX_USE_CXX11_ABI=1 -std=c++11
...

flags.make after:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.16

# compile CUDA with /usr/local/cuda/bin/nvcc
# compile CXX with /usr/bin/c++
CUDA_FLAGS =  --expt-relaxed-constexpr -Xcompiler=-fPIC   -D_GLIBCXX_USE_CXX11_ABI=1
...

Now to figure out how to fix that in CMake!

Hmm, can you share output of which c++ and which g++ commands as well as g++ version?

@malfet
root@pc:/~# which c++
/usr/bin/c++

root@pc:/~# /usr/bin/c++ --version
c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@pc:/~# which g++
/usr/bin/g++

root@pc:/~# /usr/bin/g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks for the report and fix @mattpopovich I had the exact same issue on my side, and this did help fixing it, simply add -DCMAKE_CUDA_STANDARD=14 to the pytorch vision build call. Somehow nvcc defaults to C++11 on my system (Ubuntu 20.04).
I tried adding set(CMAKE_CUDA_STANDARD 14) to CMakeLists.txt next to set(CMAKE_CXX_STANDARD 14), but this did not fix the issue, and this I can't explain though.

How can use C++17?
#error C++17 or later compatible compiler is required to use ATen.
My version:
gcc --version
gcc (Ubuntu 10.5.0-1ubuntu1~22.04) 10.5.0


cv qualifiers can break traits specializations

I noticed this as I was trying to clean up the MSVC issues. Basically, qualifiers will push us to the root_type specializations rather than the fvar<typename, std::size_t> specializations. Below is an example.
static_assert(get_depth<fvar<float, 4>>::value == 1);
static_assert(get_depth<const fvar<float, 4>>::value == 0);

I'm working through a solution, but I think we need to move away specializing on fvar<RealType, std::size_t> and should check for other traits that signal we have an fvar rather than a root_type. I think using the void_t idiom is the best way to go, since we can then require several types/fields to be present before going to the specialization meant for fvar types; we can check for depth, order_sum, and anything else to lower the probability of a root_type having those member types/fields confusing the type resolution.

Will std::decay do the job?

Yes. I used static_assert statements as above to verify the problem existed in each get_depth, get_order_sum, and is_fvar. The PR contains static_assert statements to verify the the respective solutions (which are all similar to each other).
The blueprint solution used in each case works as so:
A type is passed to an alias template, through which the type passes (transformed by std::decay) to one of two structs.
The structs (now in detail namespaces) are similar to those that existed before: one is not specialized, used previously only for non-fvar types, while the other is specialized for fvar types.
If an fvar type makes it to the unspecialized struct (as would happen with a const-qualified fvar type), that type is checked for fvar-ness, and passed to the specialized struct if it is indeed actually an fvar. This secondary check is for cases as below; that is, a nested fvar is const-qualified, which would otherwise stop the order_sum calculation.
get_order_sum<fvar<const fvar<double, 4>, 4>

Would you say this has been resolved?

Yea, this was resolved in the last PR. I’ll close this.
Sent with GitHawk


⚠ Cioos Pacific CKAN Sitemap has degraded performance

In f362b09, Cioos Pacific CKAN Sitemap (https://catalogue.cioospacific.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 6235 ms

Resolved: Cioos Pacific CKAN Sitemap performance has improved in 6c57e44 after 24 minutes.


Missing context menu

Context menu is missing until the extension is toggled off and on again in Firefox 114.0.2 on Windows. This behavior has been observed for several months already.

Consider that Copycat's context menu has been working correctly for at least two years (the last version of Firefox was released 3 years ago) and has always worked correctly in Chrome. I can only think this is a Firefox bug, and I'm afraid there is no non-hack way to fix it.
Here's the code related to the context menu:
https://github.com/BlackGlory/copycat/blob/7c7a865ad7b7125c25ef653a4ff95ce204bb95ca/src/background/index.ts#L68-L79

I've moved to MacOS with Firefox 119 and the issue is there as well. I understand that there're Firefox bugs but other extensions somehow manage to show consistently their entries in the contex menu. I hope there's a solution for this issue in this great extension. I've tried to move to alternative extensions but Copycat is the best.

Just tried to solve this problem and sadly found that debugging the relevant behavior of the extension is not possible in the latest version of Firefox:

Temporarily loaded extensions will be deleted after restarting Firefox.
Installing self-packaged extensions is not possible, one of the following two errors will pop up:

"This add-on could not be installed because it appears to be corrupt."
"This add-on could not be installed because it has not been verified."

Years later, Firefox extension development experience is still the worst, I guess I can only debug by submitting a new version (very stupid), I don't want to continue wasting time on this.

So I haven't given up yet.
It took me 20 minutes to figure out how to sign my extension without submitting a new version.
I think the problem might be related to "background.persistent": false.

v2.4.6 has just been released, which should solve this problem.


Windows Terminal leaks a file handle to the starting directory

Windows Terminal version (or Windows build number)
1.9.1942.0 (Windows version: 10.0.19043.1110)
Other Software
No response
Steps to reproduce

Create an empty directory, e.g. c:\temp\rmdir_test
Open explorer.exe and navigate to the newly created directory.
In the address bar, type wt -d . to launch a new instance of Windows Terminal with Command Prompt as the default profile.
Close the explorer window.
In the command prompt type cd .. to go the the directory above (c:\temp).
Type rmdir rmdir_test to attempt to delete the empty rmdir_test directory

Expected Behavior
I was expecting to be able to delete the rmdir_test directory without having to close the terminal window.
If I repeat the above steps using conhost instead of Windows Terminal (i.e. typing cmd.exe in the address bar instead of wt -d .), I can delete that directory just fine, with the command prompt still open.
Actual Behavior
I get the following error: The process cannot access the file because it is being used by another process.
If I look for the handle in Resource Monitor, I get this:

It seems that the Terminal retains that file handle for as long as the process is alive, even if I navigate away from the starting directory.
Seems to be similar to #9664, which was marked as resolved and closed, although I don't really see any solutions in there that would be applicable in my case...

It's still the current working directory of windowsterminal.exe and openconsole.exe.

Possibly, so?

A process always has an open handle to its current working directory.

And the current working directory stays the same forever because...?

A process keeps its working directory open without shared delete access, which prevents the directory from being deleted or renamed until the directory is closed (e.g. the working directory changes or the process terminates). Notably, the base API uses the handle for the working directory to open relative file paths (see NTAPI OBJECT_ATTRIBUTES RootDirectory), which is similar to openat() in POSIX systems.

And the current working directory stays the same forever because...?

Because "WindowsTerminal.exe" and "OpenConsole.exe" never change their inherited working directory? I guess they could change it to the system directory.

I think there are situations in which windowsterminal.exe changes its CWD ... using "Open in Windows Terminal" with a re-used instance.  IIRC, folks wanted new shells opened in "." to follow the "open in" mechanism around.  (yes/no?)

That's correct. When you've got the windowing behavior set to re-use an existing window (the second two options here:

), or when you do a wt -w N -- whatever.exe, we'll have the wt opening the commandline switch to the CWD of the source of the commandline, spawn that connection, then switch back. This is to make sure profiles that have their startingDirectory set to something like . work correctly.

So how do I force Windows Terminal to change the current working directory when I change the directory in the command prompt?

So how do I force Windows Terminal to change the current working directory when I change the directory in the command prompt?

The short answer is you can't.  Why would you want to?

Consider the following scenario:

A developer launches the terminal from a directory that contains some build artifacts (e.g. CMake configuration cache or maybe some other files generated as a part of the build process, or perhaps not even build artifacts, it doesn't really matter). She or he does some work on the command line in that directory, then switches away to another directory on the filesystem.
Over the course of the next hour(s), said developer launches a number of other terminal windows (possibly with tabs), working on some other (maybe related, maybe not) things in other areas of the filesystem.
At some point (s)he decides to build the first project. Or maybe hands over the machine to another developer who needs to do a full rebuild. In this case, certain builds are done from scratch and involve wiping clean the entire build area and resyncing the source code and all dependencies. And so that other developer triggers a full rebuild -- except now the part that does the cleanup mysteriously fails, although it used to work fine. It's not immediately obvious what is the cause and why that directory could not be deleted -- it doesn't contain any executables/dlls that could be locked by a running process, none of the open command prompts have it set as their current directory.

That's because someone else started the terminal from that directory a few hours ago.
At this point your option is to look for the handle, then try to match the PID of the process that owns it with the right instance of the terminal and close it, otherwise you won't be able run the automated build process. Not the best user experience.
And if that first terminal was actually used to start some long running process (e.g. a regression suite for another build configuration, 8+ hours total and you're on hour 4), then you're out of luck.
Mind you, all of this works with the old conhost just fine -- there are no issues with deleting the starting directory, so from our point of view, this is effectively a regression.
Not sure how it fits with the plans for making Windows Terminal the default terminal in the future.

Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to, say the system directory, but the current directory in the shell set to ".", then that would work just fine for me...

Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me...

I'm not sure what you're saying.  If the terminal's CWD is the system directory, what is "."?

Terminal already has some provisions for caching that it thinks the current working directory should be, and it already forcibly resolves relative paths. It would be trivial for us to:

Save the current WD as a path
Change the WD to System32 or something
Never call GetCurrentDirectoryW, and always rely on the saved value.

This would allow us to unlock the working directory and still work normally.

Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me...

I'm not sure what you're saying. If the terminal's CWD is the system directory, what is "."?

The directory from which I want to launch the terminal. In the example at the top of the thread it is c:\temp\rmdir_test -- that's where I want to start my shell -- meanwhile, the current working directory for the Windows Terminal process (which apparently, does not matter to me in this scenario) should be set to the system directory.

Again, when I launch a new instance of the terminal from an arbitrary directory, I want either:

For the CWD of the terminal process to track the current directory in the shell as I navigate around the file system, or:
To set that CWD to something other than the starting directory (while still starting the shell in that directory), preferably the system directory, since I will never, ever want to delete that.

The reason is that, currently, if you launch the terminal from an arbitrary directory, you cannot delete it until you close that instance of the terminal, and for various reasons you might actually want to delete it at some point. This is even more confusing, if you started your terminal some time ago (or, for example, it was launched by someone else the previous week), because there is absolutely nothing in the UI that indicates/reminds you that this is the case.

Okeydokey well it seems like Dustin's got a good idea up in https://github.com/microsoft/terminal/issues/10849#issuecomment-891245118 so let's just do that.

I think that's what @DHowett is talking about.  It'd probably also make sense to ensure that OpenConsole.exe's CWD is something innocuous.
Off-topic, but somewhat interesting ... I never noticed until today that when a console is started, conhost.exe's CWD is c:\windows.
You can get some dicey situations in a console.  Start a CMD.EXE console with CWD = directory_A.  At the CMD prompt, issue CMD and then issue CD /D directory_B.  Hand the machine over to someone else, and he won't be able to remove directory_A.

Off-topic, but somewhat interesting ... I never noticed until today that when a console is started, conhost.exe's CWD is c:\windows.

When an application creates a console session at startup, or via AllocConsole(), the base API sends the request to the ConDrv device driver using an IOCTL, and the driver in turn spawns conhost.exe from kernel mode, with the working directory set to %SystemRoot%.
In Windows 10, conhost.exe can also be executed directly, which defaults to spawning cmd.exe as the client application, unless a different executable is passed in the command line string. I think for this case conhost.exe should query and save the working directory in order to spawn the client with the desired working directory, but then change its working directory to %SystemRoot%.

You can get some dicey situations in a console. Start a CMD.EXE console with CWD = directory_A. At the CMD prompt, issue CMD and then issue CD /D directory_B. Hand the machine over to someone else, and he won't be able to remove directory_A.

CMD uses the process working directory to track its CLI working directory, i.e. the directory that's set by chdir or cd. Interestingly, PowerShell set-location (i.e. cd or chdir) doesn't change the process working directory of the pwsh.exe process.
It generalizes its working directory beyond filesystem directories (e.g. see get-psdrive), so it doesn't even bother to change the process working directory.


revise test_clear and test_cls on Windows

I'm +1, but we'll let @mambocab weigh in

Re: just passing if there are no errors: if it's good enough for Josh, it's good enough for me.
Re sys.platform == 'win32': we check if the test is running under Windows in a couple different ways in the codebase. Sometimes we just check to see if sys.platform == 'win32', as in the PR, but other times we use ccmlib.common.is_win, which instead checks sys.platform in ("cygwin", "win32") . Do we know how this test behaves under cygwin?

I don't have cygwin installed anymore because of how badly it can (and does) screw up permissions on files in Windows. I'd personally be comfortable with us dropping any attempts at formal cygwin support, but that being said, standardizing on a single way to do something in the code-base is optimal. I'll update the check to use common.is_win.

Force-pushed an update to use is_win()

Awesome, thanks.
The linter warning from Travis isn't related to this PR. Merging.


Migrate and add field 'publication_study_notes'

string field in the publication model
from the species descriptor file
originally called 'notes' in the species descriptor file

this is in comadre (and soon compadre) as publication_study_notes

So it will be called publication_study_notes in both CSVs?


Failed to fetch dynamically imported module

Laravel Vite Plugin Version: 0.2.3
Laravel Version: 9.19.0
Node Version: 16.0.0
NPM Version: 7.18.1

Description:
When build for prod if a user it's already on one page I will receive this sentry exception when this user change page Failed to fetch dynamically imported module Look like it's happening because those files vite create have different name. Do we have a way to trigger I don't know a full refresh or ? Btw I'm using React and Inertiajs
My build command "build": "vite build && vite build --ssr"

Hi @EQuimper, are you using the latest version of inertiajs/inertia-laravel (v0.6.3)? It should detect a change in the manifest and force a full page load (see https://github.com/inertiajs/inertia-laravel/pull/399).

@jessarcher thank you let me try this one and yes I was on version 0.5

No worries! I'm going to assume this is resolved - feel free to re-open if you're still having issues with the latest version of Inertia.


Swifter Authenticate doesn't seem to be working

Hi - I am using swifter.authenticate with a callback URL and while Twitter recognizes a successful authentication, the closure block is never called. Here are my steps.

Registered an app on Twitter and retrieved API/Secret keys. Also registered a callback URL of "SwifterTest://" and a website URL.

Loaded latest version of Swifter to my Xcode project via Cocoapods.

pod 'Swifter', :git => 'https://github.com/mattdonnelly/Swifter.git', :tag => '2.4.0'

Added a new URL Type with the callback URL to the Xcode project.

Added code to the App Delegate:

func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
        Swifter.handleOpenURL(url, callbackURL: url)
         return true
}

Added code to ViewDidLoad in default ViewController

let swifter = Swifter(consumerKey: "API KEY", consumerSecret: "SECRET KEY")

if let callbackURL = URL(string: "SwifterTest://") {
swifter2.authorize(withCallback: callbackURL, presentingFrom: self, success: { token, _ in
              print("SUCCESS")
}, failure: { error in
              print("ERROR")
})

I am presented with the Twitter authorization screen and I enter my ID/password and after selecting Authorize, I am presented with a dialog to open in my app, which it does successfully. I also see the authentication on Twitter. However, the callback in the authorize function is never called. I see no SUCCESS or ERROR in the logs.
Feels like some sort of setting that needs to be set. Any help is greatly appreciated. Thank you for looking.
Edited for syntax highlighting

Does the app open back up after authentication? Check if the application(:open:options:) method is actually called. I am not able to reproduce this with the sample app in Swifter.
If it is not, it is likely that you did not register the url scheme in the app so that iOS can recognize it. Something like the following should be added to your Info.plist

Ok I figured it out thanks to your help. I didn't have this Scene Delegate set up and now I have a successful authentication.
func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        guard let context = URLContexts.first else { return }
        let callbackUrl = URL(string: "SwifterTest:/")!
        Swifter.handleOpenURL(context.url, callbackURL: callbackUrl)
    }

Appreciate your help, Andy.

Awesome, glad you figured it out. Closing this now.


feat(Result): Support Ensure operator to validate result value

The Ensure operator returns a new failure result if the predicate is false. Otherwise, returns the original result.
Ok<int, string>(10)
    .Ensure(v => v < 50, "Greater or equal to 50")
    .Should()
    .BeOk(10);

Ok<int, string>(10)
    .Ensure(v => v < 10, "Greater or equal to 10")
    .Should()
    .BeErr("Greater or equal to 10");

FYI, you can also do this already with FlatMap (and implicit casts):
Ok<int, string>(10)
    .FlatMap(v => v < 50 ? v : "Greater or equal to 50")

Are you sure?

Oh, I guess the implicit casts only work for methods with a defined type signature. 😞
Looks good to me!


refactor: extract plugins crate

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?
This pr mainly extracts plugins crate, which provides functions for initializing and starting plugins for frontend/datanode/meta-srv.
Checklist

[ ]  I have written the necessary rustdoc comments.
[ ]  I have added the necessary unit tests and integration tests.

Refer to a related PR or issue link (optional)

@killme2008 @MichaelScofield @paomian PTAL 😃


Ensure correct expire date for invoices with far future expiry

Description:
The largest number (ms) supported by setInterval is<PHONE_NUMBER>. If countdown expire date is outside of this range do not use a timer.
Note: Technically if a user was to keep a countdown on the screen for over 24 days it would display an inaccurate expired message, but in practice this is probably such an edge case that it's not worth investing time into addressing at this point.
Motivation and Context:
Fix #3144
How Has This Been Tested?
Manually
Types of changes:
Fix
Checklist:

[x] My code follows the code style of this project.
[x] I have reviewed and updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes where needed.
[x] All new and existing tests passed.
[x] My commits have been squashed into a concise set of changes.

Coverage increased (+0.06%) to 22.755% when pulling f6cc3987a6ede8e6ab7dcf26f13ab10abbc10973 on mrfelton:fix/far-future-countdown into 614e97a18586643c7ecaa1d8ef268d07ef447854 on LN-Zap:master.


Unable to unlock wallet with zap since lnd walletunlocker change

See https://github.com/lightningnetwork/lnd/pull/4985
Running zap-android 0.4.0 beta
Zap error: "Access denied! The macaroon is invalid. [Retry]"
After unlocking the wallet with lncli unlock Zap works normally.

Hi,
thanks for the issue. What version of LND are you using? The PR you linked to was merged only 10 days ago which means it is not yet included in the official releases.

using master.

Yes, I haven't fixed that one yet. For now you have to unlock manually or with a different app.
This will be fixed in the next release.

This should be fixed now with the new release (0.5.3-beta). Feel free to reopen the issue if you still have problems.