rocmPackages.rocm-cmake: 6.0.2 -> 6.3.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.rocm-cmake is: CMake modules for common build tasks for the ROCm stack
meta.homepage for rocmPackages.rocm-cmake is: https://github.com/ROCm/rocm-cmake
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.1.0 in filename of file in /nix/store/k485w9x8dch0mh21h8g0lnw3s8mdx15v-rocm-cmake-6.1.0

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

96 total rebuild path(s)

96 package rebuild(s)

First fifty rebuilds by attrpath
blender-hip
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.miopen-hip
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocfft
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu
rocmPackages.rpp-hip
rocmPackages.rpp-opencl
rocmPackages.tensile
rocmPackages_6.clang-ocl
rocmPackages_6.clr

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/k485w9x8dch0mh21h8g0lnw3s8mdx15v-rocm-cmake-6.1.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.rocm-cmake https://github.com/r-ryantm/nixpkgs/archive/1cc6ac622ff9b4a1f019e4871bcc0e89ddaac891.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/1cc6ac622ff9b4a1f019e4871bcc0e89ddaac891#rocmPackages.rocm-cmake

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/k485w9x8dch0mh21h8g0lnw3s8mdx15v-rocm-cmake-6.1.0
ls -la /nix/store/k485w9x8dch0mh21h8g0lnw3s8mdx15v-rocm-cmake-6.1.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

59 packages marked as broken and skipped:

blender-hip
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.clr.icd
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.flang.doc
rocmPackages.llvm.flang.info
rocmPackages.llvm.flang.man
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.llvm.openmp.doc
rocmPackages.llvm.openmp.info
rocmPackages.llvm.openmp.man
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rdc.doc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocdbgapi.doc
rocmPackages.rocfft
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocmlir.external
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu
rocmPackages.rpp-hip
rocmPackages.rpp-opencl
rocmPackages.tensile
rocmPackages.tensile.dist
zluda

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.rocm-cmake is: CMake modules for common build tasks for the ROCm stack
meta.homepage for rocmPackages.rocm-cmake is: https://github.com/ROCm/rocm-cmake
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.2.0 in filename of file in /nix/store/rh9mfzy21ba6rdwfbfvn3y9dnhbji4p5-rocm-cmake-6.2.0

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

102 total rebuild path(s)

102 package rebuild(s)

First fifty rebuilds by attrpath

blender-hip
ollama-rocm
python311Packages.vllm
python312Packages.vllm
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.miopen-hip
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rh9mfzy21ba6rdwfbfvn3y9dnhbji4p5-rocm-cmake-6.2.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.rocm-cmake https://github.com/r-ryantm/nixpkgs/archive/0f27daa138a41c93137c0d0eedffd804c17543ec.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/0f27daa138a41c93137c0d0eedffd804c17543ec#rocmPackages.rocm-cmake

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rh9mfzy21ba6rdwfbfvn3y9dnhbji4p5-rocm-cmake-6.2.0
ls -la /nix/store/rh9mfzy21ba6rdwfbfvn3y9dnhbji4p5-rocm-cmake-6.2.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

65 packages marked as broken and skipped:

blender-hip
ollama-rocm
python311Packages.vllm
python311Packages.vllm.dist
python312Packages.vllm
python312Packages.vllm.dist
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.clr.icd
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.flang.doc
rocmPackages.llvm.flang.info
rocmPackages.llvm.flang.man
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.llvm.openmp.doc
rocmPackages.llvm.openmp.info
rocmPackages.llvm.openmp.man
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rdc.doc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocdbgapi.doc
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocmlir.external
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu
rocmPackages.rpp-hip
rocmPackages.rpp-opencl
rocmPackages.tensile
rocmPackages.tensile.dist
zluda

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.rocm-cmake is: CMake modules for common build tasks for the ROCm stack
meta.homepage for rocmPackages.rocm-cmake is: https://github.com/ROCm/rocm-cmake
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.2.1 in filename of file in /nix/store/qn7fax5k685b9pcqvccfb3kgqlxisgwf-rocm-cmake-6.2.1

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

102 total rebuild path(s)

102 package rebuild(s)

First fifty rebuilds by attrpath

blender-hip
ollama-rocm
python311Packages.vllm
python312Packages.vllm
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.miopen-hip
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qn7fax5k685b9pcqvccfb3kgqlxisgwf-rocm-cmake-6.2.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.rocm-cmake https://github.com/r-ryantm/nixpkgs/archive/58d93b771dfd4755efca771c15d5045b024f4f55.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/58d93b771dfd4755efca771c15d5045b024f4f55#rocmPackages.rocm-cmake

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qn7fax5k685b9pcqvccfb3kgqlxisgwf-rocm-cmake-6.2.1
ls -la /nix/store/qn7fax5k685b9pcqvccfb3kgqlxisgwf-rocm-cmake-6.2.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

65 packages marked as broken and skipped:

blender-hip
ollama-rocm
python311Packages.vllm
python311Packages.vllm.dist
python312Packages.vllm
python312Packages.vllm.dist
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.clr.icd
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.flang.doc
rocmPackages.llvm.flang.info
rocmPackages.llvm.flang.man
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.llvm.openmp.doc
rocmPackages.llvm.openmp.info
rocmPackages.llvm.openmp.man
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rdc.doc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocdbgapi.doc
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocmlir.external
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu
rocmPackages.rpp-hip
rocmPackages.rpp-opencl
rocmPackages.tensile
rocmPackages.tensile.dist
zluda

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.rocm-cmake is: CMake modules for common build tasks for the ROCm stack
meta.homepage for rocmPackages.rocm-cmake is: https://github.com/ROCm/rocm-cmake
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.2.2 in filename of file in /nix/store/kxa2nghxqa814pj46g5y6h8qy3kykgaq-rocm-cmake-6.2.2

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

102 total rebuild path(s)

102 package rebuild(s)

First fifty rebuilds by attrpath

blender-hip
ollama-rocm
python311Packages.vllm
python312Packages.vllm
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.miopen-hip
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/kxa2nghxqa814pj46g5y6h8qy3kykgaq-rocm-cmake-6.2.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.rocm-cmake https://github.com/r-ryantm/nixpkgs/archive/b69c37f8e77f89655d46fd2617c655af5c0c8d98.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/b69c37f8e77f89655d46fd2617c655af5c0c8d98#rocmPackages.rocm-cmake

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/kxa2nghxqa814pj46g5y6h8qy3kykgaq-rocm-cmake-6.2.2
ls -la /nix/store/kxa2nghxqa814pj46g5y6h8qy3kykgaq-rocm-cmake-6.2.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

65 packages marked as broken and skipped:

blender-hip
ollama-rocm
python311Packages.vllm
python311Packages.vllm.dist
python312Packages.vllm
python312Packages.vllm.dist
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.clr.icd
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.flang.doc
rocmPackages.llvm.flang.info
rocmPackages.llvm.flang.man
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.llvm.openmp.doc
rocmPackages.llvm.openmp.info
rocmPackages.llvm.openmp.man
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rdc.doc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocdbgapi.doc
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocmlir.external
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu
rocmPackages.rpp-hip
rocmPackages.rpp-opencl
rocmPackages.tensile
rocmPackages.tensile.dist
zluda

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.rocm-cmake is: CMake modules for common build tasks for the ROCm stack
meta.homepage for rocmPackages.rocm-cmake is: https://github.com/ROCm/rocm-cmake
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.3.0 in filename of file in /nix/store/8fdm3xra6pn6k9274apwyz71d62sczwr-rocm-cmake-6.3.0

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

102 total rebuild path(s)

102 package rebuild(s)

First fifty rebuilds by attrpath

blender-hip
ollama-rocm
python311Packages.vllm
python312Packages.vllm
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.miopen-hip
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/8fdm3xra6pn6k9274apwyz71d62sczwr-rocm-cmake-6.3.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.rocm-cmake https://github.com/r-ryantm/nixpkgs/archive/a5cc22addc1ce406ffed39a34cd6a7bddc604014.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/a5cc22addc1ce406ffed39a34cd6a7bddc604014#rocmPackages.rocm-cmake

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/8fdm3xra6pn6k9274apwyz71d62sczwr-rocm-cmake-6.3.0
ls -la /nix/store/8fdm3xra6pn6k9274apwyz71d62sczwr-rocm-cmake-6.3.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:fast_forward: 65 packages marked as broken and skipped:

blender-hip
ollama-rocm
python311Packages.vllm
python311Packages.vllm.dist
python312Packages.vllm
python312Packages.vllm.dist
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.clr.icd
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.flang.doc
rocmPackages.llvm.flang.info
rocmPackages.llvm.flang.man
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.llvm.openmp.doc
rocmPackages.llvm.openmp.info
rocmPackages.llvm.openmp.man
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rdc.doc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocdbgapi.doc
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocmlir.external
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu
rocmPackages.rpp-hip
rocmPackages.rpp-opencl
rocmPackages.tensile
rocmPackages.tensile.dist
zluda

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.

WARNING: Package has meta.broken=true; Please manually test this package update and remove the broken attribute.

meta.description for rocmPackages.rocm-cmake is: CMake modules for common build tasks for the ROCm stack
meta.homepage for rocmPackages.rocm-cmake is: https://github.com/ROCm/rocm-cmake
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.3.1 in filename of file in /nix/store/pb3hkrzsag9ddskapg69i805ijri9sf5-rocm-cmake-6.3.1

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

102 total rebuild path(s)

102 package rebuild(s)

First fifty rebuilds by attrpath

blender-hip
ollama-rocm
python311Packages.vllm
python312Packages.vllm
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.miopen-hip
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu

Instructions to test this update (click to expand)

Either download from the cache:
nix-store -r /nix/store/pb3hkrzsag9ddskapg69i805ijri9sf5-rocm-cmake-6.3.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The nixpkgs-update cache is only trusted for this store-path realization.)
For the cached download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocmPackages.rocm-cmake https://github.com/r-ryantm/nixpkgs/archive/e88b3f84f064f648cd292a7729b57499b80dd741.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e88b3f84f064f648cd292a7729b57499b80dd741#rocmPackages.rocm-cmake

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/pb3hkrzsag9ddskapg69i805ijri9sf5-rocm-cmake-6.3.1
ls -la /nix/store/pb3hkrzsag9ddskapg69i805ijri9sf5-rocm-cmake-6.3.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:fast_forward: 65 packages marked as broken and skipped:

blender-hip
ollama-rocm
python311Packages.vllm
python311Packages.vllm.dist
python312Packages.vllm
python312Packages.vllm.dist
rocmPackages.clang-ocl
rocmPackages.clr
rocmPackages.clr.icd
rocmPackages.composable_kernel
rocmPackages.half
rocmPackages.hipblas
rocmPackages.hipcub
rocmPackages.hipfft
rocmPackages.hipfort
rocmPackages.hiprand
rocmPackages.hipsolver
rocmPackages.hipsparse
rocmPackages.llvm.flang
rocmPackages.llvm.flang.doc
rocmPackages.llvm.flang.info
rocmPackages.llvm.flang.man
rocmPackages.llvm.mlir
rocmPackages.llvm.openmp
rocmPackages.llvm.openmp.doc
rocmPackages.llvm.openmp.info
rocmPackages.llvm.openmp.man
rocmPackages.migraphx
rocmPackages.miopen
rocmPackages.mivisionx
rocmPackages.mivisionx-cpu
rocmPackages.mivisionx-hip
rocmPackages.rccl
rocmPackages.rdc
rocmPackages.rdc.doc
rocmPackages.rocalution
rocmPackages.rocblas
rocmPackages.rocdbgapi
rocmPackages.rocdbgapi.doc
rocmPackages.rocfft
rocmPackages.rocgdb
rocmPackages.rocm-cmake
rocmPackages.rocm-comgr
rocmPackages.rocm-device-libs
rocmPackages.rocm-runtime
rocmPackages.rocminfo
rocmPackages.rocmlir
rocmPackages.rocmlir-rock
rocmPackages.rocmlir.external
rocmPackages.rocprim
rocmPackages.rocprofiler
rocmPackages.rocr-debug-agent
rocmPackages.rocrand
rocmPackages.rocsolver
rocmPackages.rocsparse
rocmPackages.rocthrust
rocmPackages.roctracer
rocmPackages.rocwmma
rocmPackages.rpp
rocmPackages.rpp-cpu
rocmPackages.rpp-hip
rocmPackages.rpp-opencl
rocmPackages.tensile
rocmPackages.tensile.dist
zluda

Maintainer pings
cc @Madouura @Flakebi @mschwaig for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.


[Azure]: create cluster template for marketplace

Since Azure doesn't directly support this , we should use https://github.com/microsoft/commercial-marketplace-offer-solution
to automatically create a pre-configured cluster (like we do for AWS with cloud formation)

Based on the latest update from Ivo
So his team of 5 was moved under a different VP and that VP is absorbing 300 people from around the company to work on something completely different.  They are recommending to EPIC games that they open source the work that has already been done and that they try to get the gaming studios to contribute to completing the project.  No one has stepped up yet to take over the project, but the Coalition Studio is the most likely and he will make an intro in 2 weeks after things settle down.  I'll have that call with them, but this is most likely dead.


Audiobook PDF

Hello,
I'm a student with access to Learn Computer Forensics audiobook. The audio instructions told us to navigate here to download the supplemental PDF, but there's nothing here.
Please help me get the pdf.
Thank you,
Stephanie

Hey Stephanie (@DigitalExtension),
Could you refresh and check? We've uploaded the PDF again.
Thanks,
Yashi

Awesome. It's there now.
Thank you so much.
-Stephanie
On Fri, Jan 19, 2024 at 9:23 AM yashi-packt @.***>
wrote:

Closed #1
https://github.com/PacktPublishing/Learn-Computer-Forensics-Audiobook/issues/1
as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/PacktPublishing/Learn-Computer-Forensics-Audiobook/issues/1#event-11538221753,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFDX6WVB47S4HU2C5NDYFZDYPJ6WTAVCNFSM6AAAAABBNPA7S2VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGUZTQMRSGE3TKMY
.
You are receiving this because you were mentioned.Message ID:
<PacktPublishing/Learn-Computer-Forensics-Audiobook/issue/1/issue_event/11538221753
@github.com>


Update parsing logic to use Babel type guards

Hi, it's great to see this project revived.
I was wondering if the current team might be open to new contributions.
I briefly worked on updating the sapling parser to use babel type guards instead of tokens for parsing import statements. The code becomes a lot more declarative this way, which should make it easier to maintain and extend features.
https://github.com/MajorLift/sapling/blob/a52c92be4a2312925deca829753211134546c9bb/sapling/src/SaplingParser.ts#L265-L456
If this doesn't conflict with the general direction the current team is taking, I'd love to take another stab at it. I'm interested in contributing to other areas as well.
Let me know your thoughts. :)

Awesome! I'll see if I can make it work with the updates you guys have made, and post a PR when I'm done.

@MajorLift  sounds good


Modify remote configurations on the fly

Hi, how and is it even possible to change the name of the remote configuration file for example by $host variable.
normal config setting:
pagespeed RemoteConfigurationUrl https://example.com/remote.conf;
dynamic config setting:
pagespeed RemoteConfigurationUrl https://$host/remote.conf;
I tried everything but cant get it to work. Do you know how?

Do you also have pagespeed ProcessScriptVariables on;
http {
    pagespeed ProcessScriptVariables on;
    server {
        pagespeed LoadFromFileMatch "^https?://$host/" "$document_root/";
    }
}

As I understand this loads HTML, CSS and other stuff it does not load remote config. I need to load remote config https://www.modpagespeed.com/doc/config_filters#remote-configuration


Documentation formatting problems in Ch-GettingStartedUsers.rst

Recent changes to Ch-GettingStartedUsers.rst have broken the formatting of a number of headings in the generated HTML.  For example see section <IP_ADDRESS>. in https://nexus.edgexfoundry.org/content/sites/docs/staging/master/docs/_build/html/Ch-GettingStartedUsers.html and compare it to an equivalent heading level in https://nexus.edgexfoundry.org/content/sites/docs/staging/master/docs/_build/html/Ch-CoreData.html

@jpwhitemn no problem, I'll sort it.


Change the deprecation note to use past tense

Why:
Closes #9384
What's being changed:
The tense of the deprecation note in the article
Check off the following:

[x] I have reviewed my changes in staging (look for the latest deployment event in your pull request's timeline, then click View deployment).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@CyberFlameGO
Thanks so much for opening a PR! I'll get this triaged for review :zap:


Take a look at ND4J

We should take a look at ND4J: http://nd4j.org/

@lintool where can we potentially use them in our existing code?

Here's an elaboration of this idea: I've been sitting on it for a bit to convince myself that it's worth doing.
Here's the deal: Python/Java integration has been a bit painful. However, the only magic in DL toolkits is the backprop: the feed forward part is pretty simple - it's just a bunch of matrix multiplication with activation.
So, why don't we train the model in PyTorch, "extract" the model, which is just a bunch of weight matrices, and run natively in Java? Then it'll integrate nicely with everything else in Lucene.
All we really need is a matrix library in Java, hence ND4J.

@tuzhucheng can you please summarize our findings in this thread, compared to PyTorch, and the profiling results. It appears that this is a dead end, but let's properly document our findings.

Although the model can be implemented in Java using ND4J, the running time is quite poor compared with that of Python using PyTorch.
Here are the running times for the feed forward on the raw-dev and raw-test datasets.
Java implementation using ND4J: 1260.73 real       724.20 user       726.83 sys
Python implementation using PyTorch: 40.30 real        30.30 user         4.89 sys
The Java implementation is ~20-30x slower..
If we instrument the Java program, we get the following results:

We see that the matrix operations (e.g. multiplication, sum) take up 90% of the total running time. It is unlikely we can beat the Python running time even if we attempt to optimize the Java implementation.

The measurement that matrix operations for convolution take 90% of the total running time is consistent with the observations presented by Yangqing Jia at Facebook: https://atscaleconference.com/videos/deep-learning-in-production-at-facebook/ (10:50 - 11:30 in the video): "90% of time spent on convolution". They open-sourced an "acceleration package for neural network computations" called NNPACK (https://github.com/Maratyszcza/NNPACK) to be used by high-level deep learning packages like Torch.

Hey folks - you're using a 2 year old version of nd4j. DL4j (https://github.com/deeplearning4j/deeplearning4j) has the current best practices.  If you want try benchmarking nd4j with numpy in python via jumpy: https://github.com/deeplearning4j/jumpy


R2S，6.6.63无法启动

R2S 6.6.63无法启动，还望大佬修复

R2S 6.6.63 cannot start, hope you can fix it

same here

12月3日的依然无法启动,估计是上游的问题吧？

The one on December 3rd still cannot be started. I guess it’s an upstream problem?

yeah , same here , I try it everyday with new compile but not working ! I do not know how many days i have to try to make it work again!

r3s也出现了  debug发现是上游uboot问题

R3s also had debugging and found that it was an upstream uboot problem

did you fix it?

R3s also had debugging and found that it was an upstream uboot problem

did you fix it?

上游回退了uboot https://github.com/coolsnowwolf/lede/commit/062dc200788c30fc85e7e4ffe005655ea8878f8d
不过12月16日的还是无法启动，等下次更新再试试吧

已提交PR, 等LEDE大神合并  https://github.com/coolsnowwolf/lede/pull/13232


Feature landing page optimize code

I updated landing.js to not use the getValue() function to set the property values, since getValue() is a recursive function, and I was concerned that it was slowing the page load down. However, when I tested locally using Lighthouse, the performance didn't appear to change. But I still think it's good to get away from the recursive function if we can just use optional chaining.
I also added an abort controller to the useEffect so that we can make sure to cancel requests on unmount.
I also switched to using BrowserRouter in App.js and added some missing keys in the jsx.

Let's get this deployed to the AWS development environment early next week when you have access to our AWS environment.

@briri , I'm assuming I wait to merge this PR. Looks like there are merge blockers.


squash: fix up image ID to include sha256: prefix as needed

Signed-off-by: Tim Waugh<EMAIL_ADDRESS>

Release note not needed.


When uploading feed, "uploading" spinner spins forever

For at least several minutes after the outgoing network usage dropped to zero, the "uploading..." spinner just keeps spinning. Nothing appears to be happening.

This is likely due to an exception in the GTFS load process. There is code in master to report the error, but it has not been tested.

I'm still running into problems uploading files. Now the error is reported but it's not very informative, and dismissing the dialog causes it to re-appear repeatedly. I think we determined that the error might be caused by trips that have only one stop.

Should we be moving technical tickets like this into Asana @trevorgerhardt and @mattwigway ?

Is that on production? Production is rubbing very old code; I'm hoping to
get everything moved over today but I'm having trouble with our database
provider.
On Jul 12, 2016 7:04 AM, "Andrew Byrd"<EMAIL_ADDRESS>wrote:

Should we be moving technical tickets like this into Asana @trevorgerhardt
https://github.com/trevorgerhardt and @mattwigway
https://github.com/mattwigway ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conveyal/scenario-editor/issues/119#issuecomment-232008222,
or mute the thread
https://github.com/notifications/unsubscribe/AAimrjZSQ-fNBHF37ChvrJVJAYpe05Z9ks5qU3TWgaJpZM4I6VBY
.

Yes, on production. I didn't realize it was old code, just let me know when you get a chance to update it.

@abyrd I'd say while we're migrating we can continue to discuss and use GH while there are still tickets here, but only open new ones on Asana

Makes sense @trevorgerhardt. Maybe if something's high priority and we don't want to forget about it we can tolerate some duplicates in Asana.


SACK == ACK bug

Hey, discovered a bug:
if (p->tcp.opt.sack_opt_off) {
    __iip_enqueue_obj(conn->tcp_sack_rx, p, 0);
    if (!(conn->flags & __IIP_TCP_CONN_FLAGS_PEER_RX_FAILED)) {
        IIP_OPS_DEBUG_PRINTF("loss detected (sack) : %p seq %u ack %u\n", (void *) conn, __iip_ntohl(conn->seq_be), __iip_ntohl(conn->ack_seq_be));
        conn->cc.ssthresh = (conn->cc.win / 2 < 1 ? 2 : conn->cc.win / 2);
        conn->cc.win = conn->cc.ssthresh;
        __iip_assert(conn->head[2][0] && conn->head[2][1]);

the last assert fails, because everything we sent was already ACKED, but the packet also contains a SACK, so iip thinks this is rx loss without checking, but conn->head[2][0] is null.
In my limited knowledge, you can just check if all data is already acked and not declare rx loss. Do you have another solution that is better?
I attached the pcap. The code fails on the last packet.
output.pcap.zip
Have a good day

Thank you for your message.

the last assert fails, because everything we sent was already ACKED, but the packet also contains a SACK, so iip thinks this is rx loss without checking, but conn->head[2][0] is null.

I have not been aware of this case, and the implementation has not considered it.

you can just check if all data is already acked and not declare rx loss.

Thank you for your suggestion. I believe your idea works, and I have updated the program in https://github.com/yasukata/iip/commit/3ff62fe6d543036ade4d6db3d5dcb9e9e92feecf .
Thank you very much for your detailed report and suggestion.


Remove fixed width for proper viewing on smaller screens

Some screens were forcing two lines for the navbar items and the logo before the break for small screens. Small screens were overflowing the navbar container. This fixes that.

iPad prior to this change:

iPad with this change:

We may also want to consider changing "Join Our Slack" to a one or two word item so it fits in the height better.

Fixes https://github.com/snohio/odevs/issues/21


Do we have support for OAuth1.0 and OAuth2.0 like POSTMAN Tool?

Hi All,
Currently i see we have support for Basic Authentication with username and password.
Do we have support for OAuth1.0 and OAuth2.0 like POSTMAN Tool?
Does anyone tried or used code to support httprb?
Please let me know if this is something possible with this gem?
Thanks

There is no integrated OAuth support, no.
You need to use a 3rd party OAuth library to obtain an OAuth token, then pass it using the Authorization header.


Pause music on screen lock

OS: Windows
Issue Descriptions: It would be really nice if the app would pause music when the screen is locked.
Steps to Reproduce: n/a

Something like this would be almost impossible to implement cross platform, especially since there's no API in electron to listen for that type of event.

What @jostrander said :)
Also it's very subjective I like to lock my computer and have music playing while I work nearby.  I don't believe other music players (WPM) do this either

Amazon music player for windows does this. @jostrander It never occurred to me that electron might not expose such an event. @MarshallOfSound if possible this could be a setting that the user can toggle of/on


Rancher Pipeline : Catalog App Deploy fails with similarly named app.

When using rancher pipelines and deploying a catalog app, if the name of the new app is similar to an existing app, the deployment will fail.
This is due to grep misuse in https://github.com/rancher/pipeline-tools/blob/master/bin/apply-app :
installAppFunc(){
  apps=$(rancher app ls --format '{{.App.Name}}')
  checkerr
  exist=$(echo "$apps"|{ grep $APP_NAME || true; })
  if  [[ -z "$exist" ]];then
    loginfo "installing new $CATALOG_TEMPLATE_NAME app \"$APP_NAME\" in $TARGET_NAMESPACE namespace"
    rancher app install --no-prompt -a /tmp/answers.file --version $VERSION --namespace $TARGET_NAMESPACE $CATALOG_TEMPLATE_NAME $APP_NAME
    checkerr
    waitAppActiveFunc
    loginfo "successfully installed the \"$APP_NAME\" app"
  else
  	loginfo "upgrading the \"$APP_NAME\" app"
    rancher app upgrade -a /tmp/answers.file $APP_NAME $VERSION
    checkerr
    waitAppActiveFunc
    loginfo "successfully upgraded the \"$APP_NAME\" app"
  fi
}

grep here finds all cases of similarly named app instead of exact match
Step to reproduce :

Create an app from a catalog manually and name it XXXmyname
Create a rancher-pipeline that will deploy a catalog app named myname
The pipeline will fail as it will try to upgrade the app  myname thinking it already exists due to bad grep on XXXmyname

Suggestion to replace with "grep - w APPNAME"
The flag -w limit to the exact same name

I've met the bug as you too~


Quiz exercises: Fix Visual Mode Selection

Checklist
General

[ ] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Client

[x] I followed the coding and design guidelines and ensured that the layout is responsive.
[x] I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
[ ] I added multiple screenshots/screencasts of my UI changes.

Motivation and Context

Adding spot in visual mode of short answer question of quiz exercise does not work as expected when the text to be added s located exactly beside an existing spot.
https://user-images.githubusercontent.com/10885503/204464705-711ad243-ce3c-4a78-8aa2-6f60bfef5d63.mov
Description

Steps for Testing

Prerequisites:

1 Instructor
1 Course
1 Quiz Exercise which has Short Answer Question

Log in to Artemis
Navigate to Course Administration
Select the Course
Click Exercises
Click Edit of the Quiz Exercise
Click the Visual Tab of the Short Answer Question
Highlight the text which is located exactly beside the spot
Click Add Spot
Verify that the highlighted text is added as a spot correctly

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

Class/File
Branch
Line

short-answer-question-util.service.ts
80.18%
95%

Screenshots

Codecov Report
Base: 75.63% // Head: 75.63% // No change to project coverage :thumbsup:

Coverage data is based on head (a448c75) compared to base (b27d53d).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #5905   +/-   ##
========================================
  Coverage    75.63%   75.63%
========================================
  Files         1117     1117
  Lines        44289    44289
  Branches      8364     8364
========================================
  Hits         33499    33499
  Misses        5621     5621
  Partials      5169     5169

Flag
Coverage Δ

client
75.63% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

.../quiz/shared/short-answer-question-util.service.ts
76.66% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[$500] Hold Request - Approving report that has expenses on hold removes "hold" status

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Found when validating PR : https://github.com/Expensify/App/pull/33897
Version Number: 1.4.43-6
Reproducible in staging?: Y
Reproducible in production?: N
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal team
Slack conversation:
Action Performed:
precondition: create a workspace, and invite an employee and approver

Go to https://staging.new.expensify.com/

Log in as an employee

Navigate to a workspace chat

Create a manual request

Submit the report to the approver

Navigate to the expense detail page in the submitted report

Click on 3 dots > Hold request

Enter a reason and hold request

In incognito, login in ND as the approver

Approve the submitted report

Expected Result:
The report is approved and the system message is added, the expense is still on hold
Actual Result:
The expense status "Hold" is removed, and the system message says that the " unheld this money request"
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/5611bdd1-f8e6-44eb-b967-02da2099a4c7

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01e61187168c0a96ba
Upwork Job ID:<PHONE_NUMBER>679118336
Last Price Increase: 2024-02-21

We think that this bug might be related to #vip-bills
CC @davidcardoza

This is related to our newly released Hold Requests feature (https://github.com/Expensify/Expensify/issues/274076) which is part of Wave 7.

This is the expected behavior right now - it will be handled better after we finish this issue


Rubocop syntax error displayed as warning instead of error

When a ruby file contains a syntax error, all other linter warnings are not displayed anymore, and the line with the error is displayed with the warning signs:

The corresponding error message is:
Unexpected token tIDENTIFIER (Using Ruby 2.3 parser; configure using `TargetRubyVersion` parameter, under `AllCops`)

Is this a bug or expected behavior?

I think it just shows all messages as warnings. Someone will need to have a look at the linter and figure out some way to show some messages as errors, and some as warnings. Or perhaps all messages should be errors. If someone knows Ruby better than I do, they can have a look.

@w0rp actually - other things are displayed as errors by rubocop, I believe. If we remove the line with the invalid syntax from the example above, it looks like this:

P.S. I just complained about a bug and forgot to first thank you for making ale. It's super useful, so here is a big thank you! 🎉

I like complaining. Complaining is the first step towards fixing anything.

It seems that Rubocop returns an E error code for syntax errors, but rubocop#Handle expects for C as an error. (https://github.com/w0rp/ale/blob/master/ale_linters/ruby/rubocop.vim#L29).
Changing this line to
        \   'type': index(['C', 'E'], l:type) != -1 ? 'E' : 'W',

Fixes the issue.

I have pushed that line as a fix for this now.


ISPN-10149 - Enable checkstyle plugin during the verify maven phase

I am expecting an error in server/integration/testsuite/src/test/resources/application-users.properties

Thanks @diegolovison! One minor thing, please try to remember to add the jira url to the PR description as it makes the reviewers life much easier :smile:

@diegolovison It would be good to have this on the 9.4.x branch, can you issue a backport PR please

@diegolovison I'm reading the PR/JIRA subject as "checkstyle didn't run at all before, this PR is enabling it for the first time", but I'm pretty sure I got checkstyle errors before. Can you explain in more detail what you are changing?

@danberindei @ryanemerson
Before my fix the state of ISPN was:

Diff versions for <groupId>com.puppycrawl.tools</groupId>. In other to fix it, I moved versionx.com.puppycrawl.tools.checkstyle to build-configuration/pom.xml. Now, pom.xml and checkstyle/pom.xml can see the same version. <version.checkstyle>8.1</version.checkstyle> was removed because it was duplicated and it was an old version.

Configure checkstyle plugin
The maven tree structure for the root ISPN pom.xml is:
pom.xml -> infinispan-build-configuration-parent\pom.xml ->

The maven tree structure for checkstyle project is:
pom.xml -> build-configuration/bom/pom.xml
This is why we saw the same configuration <artifactId>maven-checkstyle-plugin</artifactId>plugin in both pom.xml
I will wait for the @danberindei feedback before proceeding with the backport

@diegolovison @danberindei can we have a backport ?

Done. https://github.com/infinispan/infinispan/pull/6982


webgl build appears to be failing again

1352.0 [  7%] Linking CXX static library libibl-lite.a
1352.2 [  7%] Built target ibl-lite
1352.2 [  7%] Building CXX object filament/backend/CMakeFiles/backend.dir/src/BackendUtils.cpp.o
1352.8 In file included from /filament/filament/backend/src/BackendUtils.cpp:17:
1352.8 In file included from /filament/filament/backend/include/private/backend/BackendUtils.h:20:
1352.8 In file included from /filament/filament/backend/include/backend/DriverEnums.h:29:
1352.8 In file included from /filament/libs/math/include/math/vec4.h:20:
1352.8 /filament/libs/math/include/math/half.h:163:35: error: identifier '_h' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator]
1352.8   163 | inline constexpr half operator "" _h(long double v) {
1352.8       |                       ~~~~~~~~~~~~^~
1352.8       |                       operator""_h
1352.9 1 error generated.
1352.9 em++: error: '/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -DEMSCRIPTEN --sysroot=/emsdk/upstream/emscripten/cache/sysroot -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -DFILAMENT_DFG_LUT_SIZE=64 -DFILAMENT_ENABLE_MATDBG=0 -DFILAMENT_METAL_HANDLE_ARENA_SIZE_IN_MB=8 -DFILAMENT_MIN_COMMAND_BUFFERS_SIZE_IN_MB=2 -DFILAMENT_OPENGL_HANDLE_ARENA_SIZE_IN_MB=4 -DFILAMENT_PER_FRAME_COMMANDS_SIZE_IN_MB=2 -DFILAMENT_PER_RENDER_PASS_ARENA_SIZE_IN_MB=3 -DFILAMENT_SUPPORTS_OPENGL -DFILAMENT_TARGET_MOBILE=1 -DSYSTRACE_TAG=2 -I/filament/filament/include -I/filament/out/cmake-webgl-release/filament -I/filament/filament/src -I/filament/filament/backend/include -I/filament/filament/backend/src -I/filament/out/cmake-webgl-release/filament/backend -I/filament/libs/math/include -I/filament/libs/utils/include -I/filament/third_party/robin-map/tnt/.. -std=c++17 -fstrict-aliasing -Wno-unknown-pragmas -Wno-unused-function -Wno-deprecated-declarations -fvisibility=hidden -O3 -DNDEBUG -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti -fno-unwind-tables -fno-asynchronous-unwind-tables -Wall -Wextra -Wno-unused-parameter -Wextra-semi -Wnewline-eof -Wdeprecated -Wundef -Wgnu-conditional-omitted-operand -Wweak-vtables -Wnon-virtual-dtor -Wclass-varargs -Wimplicit-fallthrough -Wover-aligned -Werror -fvisibility-inlines-hidden -MD -MT filament/backend/CMakeFiles/backend.dir/src/BackendUtils.cpp.o -MF CMakeFiles/backend.dir/src/BackendUtils.cpp.o.d -c /filament/filament/backend/src/BackendUtils.cpp -o CMakeFiles/backend.dir/src/BackendUtils.cpp.o' failed (returned 1)
1352.9 make[2]: *** [filament/backend/CMakeFiles/backend.dir/build.make:77: filament/backend/CMakeFiles/backend.dir/src/BackendUtils.cpp.o] Error 1
1352.9 make[1]: *** [CMakeFiles/Makefile2:1583: filament/backend/CMakeFiles/backend.dir/all] Error 2
1352.9 make: *** [Makefile:136: all] Error 2
failed to solve: process "/bin/sh -c ./build.sh -p webgl release" did not complete successfully: exit code: 2

Start from a Ubuntu image with the latest version of Ubuntu
FROM debian:latest
Update and upgrade Ubuntu packages
RUN apt-get update && apt-get upgrade -y
Install necessary packages (libglu1-mesa-dev vs  libgl-dev)
RUN apt-get install -y git python3 cmake build-essential clang llvm libc++-dev libc++abi-dev libgl-dev
Set Clang as default C and C++ compiler
RUN update-alternatives --install /usr/bin/cc cc /usr/bin/clang 100
RUN update-alternatives --install /usr/bin/c++ c++ /usr/bin/clang++ 100
Clone and build Emscripten
WORKDIR /
RUN git clone https://github.com/emscripten-core/emsdk.git
WORKDIR /emsdk
RUN ./emsdk install latest
RUN ./emsdk activate latest
Set up Emscripten environment variables
ENV EMSDK=/emsdk
ENV EM_CONFIG=/emsdk/.emscripten
ENV EM_CACHE=/emsdk/cache
ENV EM_PORTS=/emsdk/ports
Add emscripten to PATH
ENV PATH="/emsdk:${PATH}"
ENV PATH="/emsdk/upstream/emscripten:${PATH}"
ENV PATH="/emsdk/node/16.20.0_64bit/bin:${PATH}"
Copy Filament into the Docker container
COPY ./filament /filament
Build Filament
WORKDIR /filament
RUN ./build.sh -p webgl release

Can you try building outside of docker?  I just did and had no issue building for web.
If it works outside of docker, I'd check what is the difference between the two.
Thanks.

What clang, emscripten versions, etc. were being used?  I'm seeing the
break w/ newer versions.
On Mon, Jul 31, 2023 at 5:05 PM Powei Feng @.***> wrote:

Can you try building outside of docker? I just did and had no issue
building for web.
If it works outside of docker, I'd check what is the difference between
the two.
Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/google/filament/issues/7013#issuecomment-1659253273,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEFL7IM7GXHEQGC6V4STIDXTAT2NANCNFSM6AAAAAA23PH7JY
.
You are receiving this because you authored the thread.Message ID:
@.***>

@poweifeng are you able to run the dockerfile an repro?  if not, let me know and i'll help.
in a directory containing dockerfile:
docker build -t filament .

Here's a working dockerfile: https://gist.github.com/poweifeng/d1be776a94b1c426dc492c95a96ea3a8
One additional comment is that we're not really resourced to debug docker issues, but if you follow the linux build instructions,
you should be able to set up a build in a container with little effort.

Would it save both of us, and others, time to simply track the dockerfile in the repo?  Like many other projects do?  We could schedule it to run once a week on some cron?

Feel free to make a pull request to BUILD.md and we can bring the issue to other team members.
However, my feeling is that we're not actively using docker for any purpose, and maintaining a path (even if it's just documentation and a Dockerfile) is overhead that perhaps we can do without.

@romainguy thoughts?  should i should keep circling back around when something breaks?  looking at the godot engine stuff, they have dockerfile's for just about everything?  perhaps that makes it a good practice?

@poweifeng looking at how the new dockerfile pins the emscripten version to 3.1.15 instead of using the latest 3.1.44, does this mean filament does not support newer c/c++ compilers rolling out?

Same error met, I use 3.1.44 emsdk.
filament/libs/math/include/math/half.h:163:35: error: identifier '_h' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator]
163 | inline constexpr half operator "" _h(long double v) {
      |                       ~~~~~~~~~~~~^~
      |                       operator""_h
1 error generated.

the clang version of emsdk is 17.0.0.
emsdk/upstream/bin/clang++ --version
clang version 17.0.0 (https://github.com/llvm/llvm-project a8cbd27d1f238e104a5d5ca345d93bc1f4d4ab1f)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Users/jacob/hack/emscripten/emsdk/upstream/bin


How reliable is it to go with react native vs. swift ?

I mean we are dealing with Drone hardware, so we want to see smooth experience with camera view and interaction with the drone.
Would react native performance be as good as if I developed a mobile app with native ? Anyone has experience of this ?

I'm actually using it for burdo.io (under development).
The package is actually using native code for the drone in Kotlin, not yet in swift.
This is only a bridge to be able to do the UI in JS and still be able to use the native SDK


rename config key from KafkaEx to :kafka_ex

The config key should match the application name so that configs can be pulled correctly when running a built release (created via exrm).

Fixes issue #27

thanks :heart:


Unable to use Promise.all to create entity records

Given this block of code:

I get the following error(s):

But the above succeeds if I iterate the list using a for-of loop:

@JS-BC this is odd since you're using an await within each promise and the code shouldn't be blocking for running these in parallel. I wonder if @cadam11 might see anything wrong with how the Promise.All is constructed?

@AN-BC @cadam11 I think this is less an MJ or typescript issue and more an issue with the underlying library we're using to make queries to the DB. Perhaps the library is unable to handle 100s or 1000s of queries at a time

Perhaps, but I doubt that.

The Promise.all() call is fine in itself, although I could strongly suggest using a helper function to manage concurrency limits and avoid exhausting thread pools or hitting memory limits.

That makes sense, if the array if very large that could be causing the issue, maybe do this in batches of 10/20/50 etc and control that with a batch size variable instead of doing them all at once.

Splicing the array into smaller chunks does the trick


Unable to change size of video

Hi Gabriel,
I love floating player, ive been using it for a little over a month and it's incredibly useful. Thank you for providing this!
I cannot seem to change the size of the video, as in, no matter what I set the size to in settings, it's always the same, about 250x150 pixels and it's not large enough for me. I'm not sure what I need to do!
I'm using chrome on windows 10 with an nvidia gtx1050, hdmi output.

Hi @izaakio
Resize a window by dragging the edges or corner of the window, like this:

At the moment we cannot set the width or height for native picture in picture.
Go to the options page and uncheck "Use native Picture in Picture" to show the browser popup which supports width, height and position. In this case you'll need to install Deskpins to keep the popup always on top.

Thank you so much Gabriel!
On Fri, 2 Nov 2018 at 04:21, Gabriel B<EMAIL_ADDRESS>wrote:

Hi @izaakio https://github.com/izaakio
Resize a window by dragging the edges or corner of the window, like this:
[image: ezgif-1-0f1b8911a22d]
https://user-images.githubusercontent.com/3298817/47868568-42a19300-dde3-11e8-9fa8-af78b8cc2b0a.gif
At the moment we cannot set the width or height for native picture in
picture.
Go to the options page and uncheck "Use native Picture in Picture" to show
the browser popup which supports width, height and position. In this case
you'll need to install Deskpins to keep the popup always on top.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gabrielbarros/floating-player/issues/27#issuecomment-435123447,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqmDqgccNgV_MdJ840vRAtGfBBOU_y0Gks5uqzSvgaJpZM4YF4G4
.

You're welcome. Have a nice day!


RESTEASY-1839: SseEventSourceImpl unexpected behavior

https://issues.jboss.org/browse/RESTEASY-1839

@NicoNes  I recently fixed couple of issues about reconnect and handle 204 response in SseEventSource . Can you please check if this works for the test case you add ?

Hi @jimma,
I was your fix about reconnect and 204 and they does not pass the tests cases I added:

We are expecting the SseEventSource connection to fail when a response other than 200 is received.
In this case, it must be closed and must notify:

error listeners since it is an unrecoverable error.
completion listener since no further events will be received.

With your fix 201 for example is as a valid response. =>KO

We are expecting the SseEventSource connection to fail when a 200 response with a Content-Type header unspecified
or other than text/event-stream is received.
In this case, it must be closed and must notify:

error listeners since it is an unrecoverable error.
completion listener since no further events will be received.

With your fix:

a 200 response with Content-Type : */* is a valid response => KO
a 200 response with Content-Type: text/plain is not a valid repsonse this is OK but is does not notify any listeners nor close the SseEventSource=> KO

We are expecting the SseEventSource to close itself and not try to reconnect on a 204 response.
In this case, it must be closed and must notify:

completion listener since no further events will be received.
Error listeners are not notified in this case since it is a normal behavior.

With your fix 204 response des not notify the completion listeners => KO

We are expecting the SseEventSource to reconnect when the connection is closed (gracefully or not).
In this case, no error listener will be notified since it is not an unrecoverable error since we are trying to reconnect.
Completion listener will not be notified neither since other events will be received.

With your fix gracefull close does not trigger reconnect  => KO

With your changes 201 for example is as a valid response. =>KO

Can you explain why we need to handle like  this ?  The consumers for other media type all reads the response if the http response is 201 .

a 200 response with Content-Type : / is a valid response => KO

It's MediaType compatible:
https://github.com/eclipse-ee4j/jaxrs-api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/core/MediaType.java#L329

a 200 response with Content-Type: text/plain is not a valid repsonse this is OK but is does not notify any listeners nor close the SseEventSource=> KO

Why does it require to notify listener ?  is it a unrecoverable error ?  I didn't find jaxrs spec says something about this.  Will SseEventSource  reconnect for this target if it doesn't close ?

With your changes 204 response des not notify the completion listeners => KO

There is no content and isn't started, do we need to call completion listener ?

With your changes gracefull close does not trigger reconnect => KO

Spec group are discussing this: https://github.com/eclipse-ee4j/jaxrs-api/issues/599

With your changes 201 for example is as a valid response. =>KO

Can you explain why we need to handle like this ? The consumers for other media type all reads the response if the http response is 201 .

https://html.spec.whatwg.org/multipage/server-sent-events.html#sse-processing-model => "Any other HTTP response code not listed here, as well as the cancelation of the fetch algorithm by the user agent (e.g. in response to window.stop() or the user canceling the network connection manually) must cause the user agent to fail the connection." => 201, 401... for example are not valid.
Browsers work that way.

a 200 response with Content-Type : / is a valid response => KO

It's MediaType compatible:
https://github.com/eclipse-ee4j/jaxrs-api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/core/MediaType.java#L329

https://html.spec.whatwg.org/multipage/server-sent-events.html#sse-processing-model => "HTTP 200 OK responses with a Content-Type header specifying the type text/event-stream, ignoring any MIME type parameters, must be processed line by line as described below....HTTP 200 OK responses that have a Content-Type specifying an unsupported type, or that have no Content-Type at all, must cause the user agent to fail the connection."
Browsers work that way.

a 200 response with Content-Type: text/plain is not a valid repsonse this is OK but is does not notify any listeners nor close the SseEventSource=> KO

Why does it require to notify listener ? is it a unrecoverable error ? I didn't find jaxrs spec says something about this. Will SseEventSource reconnect for this target if it doesn't close ?

Yes it is an unrecoverable since the media type is not valid (according to the SSE spec https://html.spec.whatwg.org/multipage/server-sent-events.html#sse-processing-model, the client must "fail the connection"). And once the connection is failed the eventsource will not reconnect (https://html.spec.whatwg.org/multipage/server-sent-events.html#fail-the-connection)=> unrecoverable
Browsers work that way and does  not perform reconnection

With your changes 204 response des not notify the completion listeners => KO

There is no content and isn't started, do we need to call completion listener ?

According to the Java doc the completion listener is to be called when no more events will be received.
And yes it is started since open() has been invoked.

Please note  https://html.spec.whatwg.org/multipage/server-sent-events.html#sse-processing-model is the spec for html5 javascript. And jaxrs 2.1 spec says it is inspired by that and there could be some change for different language, and SSE should work in jaxrs runtime with other jaxrs apis.

According to the Java doc the completion listener is to be called when no more events will be received. And yes it is started since open() has been invoked.

But http 204 implies no event is received from beginning, it doesn't make sense to call completion handler.

Please note https://html.spec.whatwg.org/multipage/server-sent-events.html#sse-processing-model is the spec for html5 javascript. And jaxrs 2.1 spec says it is inspired by that and there could be some change for different language, and SSE should work in jaxrs runtime with other jaxrs apis.

I agree with you, but except for the handling of 503 that is not specificed in the HTML5 specs and that is only in the Java spec. Is there any reason not to follow this spec on the points I spotted?

According to the JAVA spec (9.3): "A resource method that injects an SseEventSink and produces the media type text/event-stream is an SSE resource method." => so valid content-type seems to be strictly text/event-stream not all types compatible with it. =>Will work with other JAXRS api

About handling response other than 200: The JAVA spec does not say nothing about this and does not provide any mech for user to set it or override it. So I guess it's up to implementor to decide. So since there is no way to overrride it  implementor should better use 200 since it the only response handled by browser. And if we are pretending to do SSE we should better ensure that at least browser will understand it as SSE.
So if server side should always send 200 why should we consider other response code (except 204, 503) as valid in SseEventSource.

According to the Java doc the completion listener is to be called when no more events will be received. And yes it is started since open() has been invoked.

But http 204 implies no event is received from beginning, it doesn't make sense to call completion handler.

SseeventSource works in an asynch fashion so there is to be a callback to notify user who invoked eventSource.open() that this event source is over and will not received any event more. To my mind this is one of the purpose of the completion hanlder. According to the java spec it must  be seen as an handlers for SseEventSource life-cycle
Suppose the following code with d a resource too be closed when it will no longer be used. Without completion notification how could we know whento close it:
 public static void main(String[] args)
      {
         SseEventSource eventSource = ...;
         MyCloseableDispatcher d= ...;
         eventSource.register(e -> {
            d.dispatch(e);
         }, t -> {
         }, () -> {
            d.close();
         });
      }

Other questions:

Should 204 be treated as unrecoverable error ? => According to me it's not an error. NO
Should 503 with retry-after set be treated as unrecoverable error ? => According to me it's an error with reconnect as a recovery mech so it's not unrecoverrable. NO
-Should other non 2xx be treated as unrecoverable error ? => According to me  there are real uncoverrable errors with no reconnect. YES

Are you OK with the fact that just calling state.set(State.CLOSED); in run() method is not enough to close the SseEventSource ? We should also close the connection and shutdown the executor.

However the JAVA spec does not say nothing on the 204 neither and we choosed to handle it as the HTML5 specs says to. So maybe a spec clarification will be needed on this whole point too. WDYT?

Sure. We can always talk with jaxrs spec group to get some clarification and get it improved in the next release version.
About the completion listener/ onComplete callback, this is the new api when Flowable was introduced in jaxrs api: https://github.com/jax-rs/api/blob/nio/jaxrs-api/src/main/java/javax/ws/rs/sse/SseEventSource.java#L238 .  It is intended to be called inside subscriber.onComplete()  and  jaxrs 2.1 spec has some javadoc for this callback : onComplete callback is invoked when there are no  further events to be received. onComplete callback is the thing to be invoked after the event consumer doesn't receive any event.  For http 204 response, it doesn't trigger any consumer, so we don't need to call this callback. I might be wrong on reading this.  But we can always ask spec group to get more clarification.

Are you OK with the fact that just calling state.set(State.CLOSED); in run() method is not enough to close the SseEventSource ? We should also close the connection and shutdown the executor.

I didn't think this in depth and I'll look at your change.

Ok I'm waiting for your feedback on my changes and I'll ask the spec group for more clarification.
Thanks

Clarification requested: https://github.com/eclipse-ee4j/jaxrs-api/issues/606

@asoldano, @jimma I've asked expert group for more clarification on few points. So if you're OK I suppose that this PR can be put on hold for now.
Thanks

@NicoNes  Sure. Let's wait the clarification from spec group.

Hey guys,
The expert group stated about that (https://github.com/eclipse-ee4j/jaxrs-api/issues/606) and it is already packaged for a future release:

https://github.com/eclipse-ee4j/jaxrs-api/pull/670
https://github.com/eclipse-ee4j/jaxrs-api/pull/833

So if you agree I will review my PR based on what I've been stated and all the changes that was made in the code since I created.
Thanks

Thank you for the contribution. We are cleaning up older PR's that seem to be stale. If you feel this is still an issue please feel free to re-open.


Add ability to exclude certain class instances from being dumped

As per:
https://github.com/raveren/kint/issues/185
Example use with Symfony2:
$_kintSettings['excludeClassInstances'] = ['\Symfony\Component\DependencyInjection\Container'];
and then the DIC doesn't get dumped which helps a lot.

Hope this is what you meant?
Thanks.

I'm sorry, but this is a bad approach for this, I'm leaving the related issue open, but I can't accept this PR.

Ok. Any pointers on what would be the correct way?

If there was an easy way, I would have done that already :) What's clear, this should be an inbuilt feature consistent with the rest of the codebase, while your solution (even if it covers the desired functionality well) relies on an unrelated feature and not only does the code become less self explanatory (i.e. surprising), but that whole feature (custom object parser) becomes burdened and more difficult to change, improve or refactor.
I have added a maximum complex item count in my private branch so Kint would not display the humongous framework objects, I'm still testing it out though, but it would fulfill part of the real reason this issue exists...

I mentioned I was working on a large rewrite. It's delayed by other things. Once it's done this should be doable with a parser plugin (Similar to the custom data/object handlers in kint now, but easier to use from the outside)

Thanks for the explanation guys - makes sense. Looking forward to the release of the feature.


enhancementappend exception check for jni code.

Proposed changes
Because in jni, we need to manually check for exceptions thrown, and if we do not handle the exception, the program will continue to execute, which is not like the try catch logic we often use. Therefore, in order to reduce the potential risks caused by not handling exceptions, I checked most of the jni code and added exception detection for it.

run buildall

run buildall


Upgrade to Kotlin 1.9

Upgrade to the latest Kotlin version. No major new functionality that's relevant
for our code, but there are a couple minor improvements:

The values() method on enum classes is now discouraged (but still supported,
since it's needed for Java compatibility) and instead there's a new entries
property which is more efficient and returns a list rather than an array.
The until infix function for creating numeric ranges now has a symbolic name
..< which makes it visually clearer that the upper bound is exclusive.

Current dependencies on/for this PR:

main

PR #1308   👈

This comment was auto-generated by Graphite.


[Ingress] 0.8.4 Release?

I understand ingress is being moved to kubernetes/ingress so if issues are being move there feel free to close this and I'll reopen there.
Could we push a 0.8.4 release of the nginx-ingress controller?  The last one was released awhile ago
$ gcloud alpha container images list-tags gcr.io/google_containers/nginx-ingress-controller

820c338dc22e  0.8.3  2016-08-22T11:59:22

@r2d4 I'm sorry for the delay. As you realized Ingress is being moved to kubernetes/ingress.
The reason for the delay is the refactoring done to the controller (temporal place https://github.com/aledbf/ingress-controller)

Could the already merged changes here on contrib perhaps be pushed out as an 0.8.4.alpha1 or alternatively an alpha kubernetes/ingress release?
It seems like lots of important small improvements and fixes here over the last 6 months are neither being used nor tested while the refactoring project happens. If we had even an untested alpha or rc release from either contrib or ingress then we could contribute to testing and share some of that work.

It seems like lots of important small improvements and fixes here over the last 6 months are neither being used nor tested while the refactoring project happens

That's not correct. Here's is where I put the temporal images when I close a PR
https://quay.io/repository/aledbf/nginx-ingress-controller?tab=tags
0.55 contains the refactoring from the PR https://github.com/kubernetes/ingress/pull/95

Here's is where I put the temporal images when I close a PR
https://quay.io/repository/aledbf/nginx-ingress-controller?tab=tags
0.55 contains the refactoring from the PR kubernetes/ingress#95

Thanks @aledbf that's great news they are builds we can test! And thanks for the 0.55 reference. Is there a way to map between those images and the PR that created them? Or the other direction, from the PR -> Travis CI -> image?

And thanks for the 0.55 reference. Is there a way to map between those images and the PR that created them?

Not yet. I've been working in that too but still is a work in progress.
https://github.com/kubernetes/ingress/tree/master/hack/e2e-internal

Closing this, there are now pre-alpha releases in the kubernetes/ingress repo https://github.com/kubernetes/ingress/releases


fix: Port already in use during build

Fix for https://github.com/remcorakers/aem-docker-getting-started/issues/1

Thanks for this fix, @sveneh !


TS-4838: CONNECT requests get forgotten across threads.

What happens here is that ProxyClientTransaction::adjust_thread
reschedules the transaction onto a new thread at the start of
HttpSM::do_http_server_open.
Unfortunately, at this point the default handler is
HttpSM::state_raw_http_server_open. When the transaction is
rescheduled, the default handler runs, and receives the EVENT_INTERVAL
that it so fortuitously logs an error for. We have never actually
completed do_http_server_open, so we never make any more progress
on this transaction.

Looks right.  Had fixed it in HttpSM::state_http_server_open but missed the raw open case.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/665/ for details.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/769/ for details.


deps: bump rbac version to 0.6.0

Thanks for submitting a PR! Please check the boxes below:

[X] I have run pre-commit to check linting
[X] I have added information to docs/ if required so people know about the feature!
[X] I have filled in the "Changes" section below?
[X] I have filled in the "How did you test this code" section below?
[X] I have used a Conventional Commit title for this Pull Request

Changes
Bump rbac version to 0.6.0
How did you test this code?
N/A

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

Comparison is base (f770ff1) 95.99% compared to head (a49bb82) 95.99%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3211   +/-   ##
=======================================
  Coverage   95.99%   95.99%
=======================================
  Files        1062     1062
  Lines       32265    32265
=======================================
  Hits        30973    30973
  Misses       1292     1292

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


Fix missing path normalization, causing empty sourcesContent in source maps.

If source maps already exist for the files being bundled, and if those source maps have their "sourceRoot" set to anything other than an empty string (such as "/" or "../"), then the builder fails to include the original source content in the source map for the bundle.
This happens because line 48 in sourcemaps.js fails to take into account that the source path may already be absolute, or if is relative, that it needs to be normalized.
This lack of normalization becomes a problem in line 85, where the source map itself has been normalized, while the keys for which the source content were stored are still the non-normalized paths - and therefore, the original content is not found. When it then tries to load the content from the original source file, it fails again if the original source maps had its "sourceRoot" set to an absolute path, as map.sourceRoot would then have been incorrectly prepended to the path.
This pull request fixes this, so if the path is already absolute, it is used as-is, and and if it is relative, it is normalized. This means source content is now correctly loaded from existing sourcemaps and included in the source map for the bundle - or if the original source maps do not contain the content, correctly loaded from the original source files.

@thomas-darling maybe you could add a test or two similar to this one? https://github.com/systemjs/builder/blob/master/test/sourcemaps.js#L97-L101

@asapach it would definitely be good to have tests for this, but I can't really afford to spend any more time on this right now, unfortunately. So for now, this will have to do - I'll keep it in mind for later though, as we have a pretty strong interest in making sure this stuff works correctly.
By the way, my second commit here ensures it checks correctly for absolute paths, and resolves an issue where absolute source paths were incorrectly changed to relative paths in the source map for the bundle.

This may have caused an issue here - https://github.com/jspm/jspm-cli/issues/2361.

There seem to be more reports coming in there. I just don't have the time to debug source maps right now in my life. If anyone is able to help that would be great, otherwise I will just revert if there are more issues.

Well, it makes no sense to revert it, as it fixes some pretty serious bugs.
I think the issue here is pretty clear - after the change, we are preserving absolute paths, which means that paths starting with /, \ or C:\... are preserved, where they were previously made relative.
I'd argue this is the correct behavior, and that if you don't want absolute paths in source maps, then you should not create them with absolute paths when building the code in the first place :-)
Also, I'm willing to bet that many people switched to absolute file system paths because the relative paths were broken before - we were down that road too.
Now, if you want to revert to the old behavior for absolute paths rooted in a drive letter, then all we have to do is to replace that last path.isAbsolute with a more explicit check for a leading / or \ :-)

There may be some steps in the conceptual model where the individual intermediate source maps by the compilers use absolute paths as the intermediate processing step, before being made relative at the final concatenation step. See https://github.com/systemjs/builder/blob/master/compilers/compiler.js#L20.
This was done so that source maps can be concatenated at the final step without having to renormalize each one individually first.
The issue might then be to make this absolute treatment in this PR compatible with that. Let me know if that sounds like the right sort of assessment, I may be completely off here too.

That is, file:///path/to/x.js is used in the intermediate representation, although it doesn't look like that would be caught by the isAbsolute here actually at all. If so, then it may just be the actual absolute cases that are failing correctly.

Yeah, I can't claim to have a full understanding of every possible code path that might lead to this function, but based on my fairly extensive debugging of the original issue, I'm reasonably sure just changing that isAbsolute to a more explicit check would do the trick - because as you say, the file:// paths were never affected by the changes :-)
I guess the question is whether this should be considered a bug at all though? As noted before, this now preserves the original, absolute sources, which is what I would personally expect.
I think the issue people are facing might be, that Chrome can't load source maps from just a file system path - previously such paths were made relative, and that's why it kind of worked, although I could imagine it might sometimes behaved in unexpected ways. But maybe the more correct way to resolve this, would be to simply ensure absolute paths rooted in a drive letter are always turned into file:// paths, which I believe Chrome can load.
Alternatively, I would not object to just just making that isAbsolute check more explicit... I don't really see any valid reason to use absolute paths rooted in a drive letter anyway, so whatever works for those who prefer that... :-)
Thoughts?


chore(demo-playwright): test for tui-error

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring
[ ] Build or CI related changes
[x] Tests related changes
[ ] Documentation content changes

What is the current behaviour?
Addresses https://github.com/taiga-family/taiga-ui/issues/4912
What is the new behaviour?
This PR adds an e2e test (with playwright) for tui-error

@nsbarsukov thank you for the comments, have addressed them


[release/3.1] Update to July 2020 3.1.106 release (3.1.6)

https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1.6/3.1.6.md

This is delayed because the tagging infrastructure failed (and related factors): https://github.com/dotnet/arcade/issues/5686#issuecomment-658456350.


IsOffscreen has wrong value.

I am working with a UI tree element from Infragistics and I've encountered that the nodes within this tree have the IsOffscreen property set to true, which must be incorrect, since the nodes are clearly visible on screen.
The attached screenshot should illustrate the situation quite well:

I've been through Microsoft's API description of the IsOffscreen-property and I checked against all what it says, concerning the scrolling viewport visibility, the partial visibility, the collapsed- and expanded visibility, etc. and none of those things apply to my UI tree.
And since I keep stumbling across such issues within the UIAutomation framework from time to time, I'd guess it's simply a bug within the framework.
Best regards,
Markus

The bounding rectangle property looks not correct, most of the cases providers calculate the property using its bounding rectangle.


Fix error where renaming spider causes it to overwrite another spider

Raise error in the schedule too

Can you include tests for this and add the validation in the frontend as well? @ruairif


update docs

This seems like a PR just to boost hacktoberfest numbers. I'm marking this as invalid and closing it on that basis.
Should you feel this is not the case, feel free to reopen this, and please add some documentation as to what you're looking to work towards as part of this pull request.


Display QR code for thé current slide

In all the conferences you can see people taking pictures of slides.
To make it simpler and greener 😜 display a QRCode on every slide to get the slide URL.

--qrcode is now available ;)


Added some validation to handle bad URLs

Added some validation to help deal with bad/wrong input URLs (which was causing segmentation faults & crashes).

Thanks for your contribution @SecGus , we appreciate it!
We also have a Discord server, which you’re more than welcome to join. It's a great place to connect with fellow contributors and stay updated with the latest developments!


Events with a large stack trace are silently ignored

Using version 4.0.2, events with a large enough stack trace will be silently ignored by bugsnag-ruby. In particular, Bugsnag::Helpers.trim_if_needed will remove the entire event rather than truncating its contents.
The ignored events I've seen contained three exceptions with approximately 200 items in the stacktrace field.

Thank you for the report, @braddunbar. I dig some investigating to determine the best way we can selectively drop parts of the payload and not have requests rejected due to size. The results are in #295.
If you have the time, can you send a copy of an example stack trace with 200 or so lines to<EMAIL_ADDRESS>I'd like to gather data and determine if there are heuristics we can apply to which lines of a stacktrace are dropped on the client side in cases like this. In the meantime, it will perform a truncation of the end of the stack trace array.

Resolved with the release of 4.1.0.

Sure thing! I've just sent the stacktrace to the email above. Let me know if you need anything else and thanks for the quick turnaround! 👍🏻


Print validation results in submit

task of #312
Still requires #352 to be fixed to actually show something.

Coverage increased (+0.03%) to 77.053% when pulling b82ff1df2180c2446f7fa9e2a27dbe18f5de264f on validatoin-results-in-submit-juha into 92a5fc03d52a0da90c62a298ba21aa6d26b6e2d1 on master.

Coverage increased (+0.03%) to 77.053% when pulling b82ff1df2180c2446f7fa9e2a27dbe18f5de264f on validatoin-results-in-submit-juha into 92a5fc03d52a0da90c62a298ba21aa6d26b6e2d1 on master.

Coverage increased (+0.03%) to 77.83% when pulling 6546c5b5d495c503e947c2b895fafb4e442e684f on validatoin-results-in-submit-juha into d3f2bd5209324291e79abd7c8d4cdfe99d6cca81 on master.

LGTM.


Ambiguity in E2E-CLI-044 - Kics scan command with --exclude-severities does include severities instead

Expected Behavior
The --exclude-severities specifies config option should NOT execute query-ids provided in the flag.
Actual Behavior
The --exclude-severities specifies config option does execute only query-ids provided in the flag.
Steps to Reproduce the Problem

Running with --exclude-severities high outputs:

Limited to Severities from config: high

Following testcase is passing, because the case expectation/annotation is wrong – expecting "only" instead of "not":

./e2e/testcases/e2e-cli-044_scan_exclude-severities.go:
// should only execute query-ids provided in the flag.

Version: v1.6.8
Platform: linux/macos

Hi @suculent, hope you are doing great!
The test case you are mentioning is working as expected.
It has 4 scan scenarios that are later compared with the expected output according to the exit code.
You can find more information regarding the KICS exit code here.
Let me know what you think.

Well, for me the exclude function does not really work as expected and the test case comment refers to inclusion as opposed to exclusion.

Hi @suculent,
The test you referred to above had an incorrect description and it is being fixed in PR #6114
From the behavior, you are describing perhaps you want to use --include-queries instead of the --exclude-severities.
Feel free to explore our documentation to find all the flags you can use with the kics scan command.
Let me know if this helps.

Anything will be good, once it will work as expected. I would prefer --include-severities instead of --exclude-severities but that does not exist by the docs.


In R: get_type -> soma_type

Conforms code to spec at https://github.com/single-cell-data/SOMA/pull/42. This change has already been implemented in Python.

There is nothing in apis/r to be changed.


Support for RN>=0.25

Tested with RN 0.26.2.

👍 will merge today!
Thanks @mat2maa!

Can you separate the following commits?
I don't want to merge the RN>=25 support with the other changes.

Apologies, I thought you had already merged. I've split of my changes into a separate repo and force pushed a reset back to the relevant commit on this fork.

Sorry @mat2maa 😢
I didn't have time to do it on Friday, apologies.

:smile: No worries @alvaromb, thanks for the useful component!

Merged and published https://github.com/APSL/react-native-floating-label/releases/tag/v0.2.2


Request throwing error when status code is 500

Package version
9.1.0
Describe the bug
@thetutlage
Why does the client throws an error when the request return a 500 status code?
It makes no sense to me, including the fact that at the docs we have this:
if (response.hasFatalError()) {
  response.error()
}

How could i access reponse.hasFatalError if when the fatal error occurs the client just throw an error and the test stop?
Even if i make a .catch block, the returned value has a prototype of Error, not ApiResponse
Reproduction repo
No response

Throwing for 500+ errors is weird. They can be valid responses thrown intentionally (a handled and/or expected error you don't want to report to the user).
Also, not having the ApiResponse object to assert with is worse DX, in my opinion. If you want to ensure the request isn't 500, you can just assert so on the ApiResponse. If you want to assert something about the response (for example: "Server is down for maintenance" vs. "Server is temporarily overloaded" for 503), it's easier to assert bodyContains.

We have received quite a few requests for this, so I think many people find throwing exceptions a bit weird. Should we handle 500 exceptions the same way as we handle other exceptions? @RomainLanz @Julien-R44  What you guys think?

Yup, i agree. would be better to be able to make assertions instead of wrapping the test with a try/catch or whatever

Okay, let's do it then. It will be a breaking change.

Hi, running into this issue, change is it still planned ? Is there a workaround meanwhile ?


on backend registered, reconnect to terminals

fixes https://github.com/microsoft/vscode/issues/159639
Such that the view and its state does not determine when terminals are reconnected to so tasks get reconnected ASAP

maybe this approach is wrong. in wsl, i'm seeing two terminals get created on reload that pt to the same xterm instance

I had the wrong approach here


Drift correction

need to consider how to implement a linear drift correction procedure.

I have written a function for this, but its implementation in the workflow needs to be addressed.

this is complete.


groupByTextProvider fires too soon

First off, thanks for a great control for ng. Am finding plenty use in my app. Q - the options attribute is being populated by a web api call to retrieve the dropdown contents. However, this control also employs groupByTextProvider to group by a field in the data. Problem is that the groupByTextProvider callback runs before the web api call returns to populate the options attribute and so the grouping doesn't work.
My current workaround is to load the options data earlier in the program and have it about in readiness for the view that has the groupByTextProvider. Any ideas how I can delay the grouping action or otherwise fix it better than I have?
Thanks again,
John K

I'm looking at version 1.5.2 right now (downloaded with Bower). You can see if it helps your situation to change line 112 from $scope.$watch('options', function (newValue) { to $scope.$watchCollection('options', function (newValue) {
This change helped my app get grouping to work better for data coming over a web api. I'm still experimenting with other modifications for the rest of my situation but thought this might help you.

@pickettd Cheers, David


User Sessions

[x] implement express-session
[x] update where appropriate to include req.session data
[x] set up sequelize connection to store session data

Awesome job, Mark!