The SDK 'Microsoft.NET.Sdk' specified could not be found.   (Monterey, MacOS)

I have an console application based on DotnetCore 5.0. It compiles and runs, but the C# extension in VSCode doesn't.
In OmnisharpLogs i see this:
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /Users/Myself/Git/myProduct/myProduct-tests/myProduct.csproj
It was not possible to find any installed .NET SDKs.
Install a .NET SDK from:
  https://aka.ms/dotnet-download
[fail]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '{projectFilePath}'.
Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.Sdk' specified could not be found.  /Users/Myself/Git/myProduct/myProduct-tests/myProduct.csproj
  at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject (System.String errorSubCategoryResourceName, Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, System.Object[] args) [0x00040] in <080b3b7730fe4c7889aaf13e0d778492>:0

Here's dotnet info:
 dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.207
 Commit:    b2bfcafcec

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  12.0
 OS Platform: Darwin
 RID:         osx-x64
 Base Path:   /usr/local/Cellar/dotnet/5.0.207/libexec/sdk/5.0.207/

Host (useful for support):
  Version: 5.0.10
  Commit:  52296950a9

.NET SDKs installed:
  5.0.207 [/usr/local/Cellar/dotnet/5.0.207/libexec/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.10 [/usr/local/Cellar/dotnet/5.0.207/libexec/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.10 [/usr/local/Cellar/dotnet/5.0.207/libexec/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

It seems like Omnisharp is the only thing that doesn't quite know where to look, can you help me on the right track?

Ended up purging every SDK and using brew to install dotnet6 and just updating to that instead. Seems to work


Allow smarter weights (cubes, coordinates, cell measures, or ancillary variables) for aggregation

🚀 Pull Request
Description

This PR allows using cubes, coordinates, cell measures, or ancillary variables as weights.
Example:
cube.collapsed(['latitude', 'longitude'], iris.analysis.SUM, weights=area_cube)

or
cube.collapsed(['latitude', 'longitude'], iris.analysis.SUM, weights='cell area')

This automatically handles potential unit conversions (e.g., multiply by m2 for area-weighted sums).
Closes https://github.com/SciTools/iris/issues/5082.

Consult Iris pull request check list

Thanks for review @lbdreyer! I think I addressed all your comments, let me know if you need anything else. :+1:
About the line in the __array_finalize__ method of Weights that is not covered by tests:
I copy-pasted this from https://numpy.org/doc/stable/user/basics.subclassing.html#slightly-more-realistic-example-attribute-added-to-existing-array. However, if I understand the description of the __array_finalize__ in the docstring here correctly, then obj can only be None if the __new__ method of the child class calls the __new__ method of the parent class (here: np.ndarray) directly. Since the __new__ method of the child class does not do that but only uses np.asarray(...).view(cls), I think obj can never be None here, so we could probably safely remove this line. My only question would then be why the example uses this line? Maybe I overlooked something?

The linkcheck reports that the Twitter link is broken
 community/index: line   28) broken    https://twitter.com/scitools_iris - 403 Client Error: Forbidden for url: https://twitter.com/scitools_iris

For me that link works. Not sure if this is related to this PR.

I just re-ran the link check and it’s OK now.


[BUG] Prop col-num not applying in mount

Hi!!!
i've a problem with the col-num/colNum prop that is not applying at the creation of the component but it works if i change after mount.
I'm trying to set to 24 in mount but impossible.

try async, beacuse there is a nextTick in the mounted function of grid layout
const colNum = ref(12)
onMounted(() => {
  nextTick(() => {
     colNum.value = 24
  })
  // or
  setTimeout(() => {

  })
})

I've discovered that enabling is-draggable and is-resizable turns default col-num (12) again. Finally i did the next using a watcher because nextTick is not working alone:
colNum.value = 12 nextTick(() => {   setTimeout(() => {      colNum.value = customizedWidthSize   }, 100)   })   // or

Hey, I tried your trick @jousepo, but when I'm moving grid item, colsNum goes back to default, here is a quick video :
https://github.com/xhlife/vue3-grid-layout/assets/171169343/b51d1d74-b2f4-4148-aa39-5d394757102e
Any idea on how to solve this ?

try with this props:
:use-css-transforms="false" :responsive="true" breakpoints="{ lg: 768, md: 500, sm: 500, xs: 480, xxs: 0 }">


Example update: Replace AccessToken with Dummy String for MSRC Compliance

Choose a PR Template
Switch to "Preview" on this description then select one of the choices below.
Click here to open a PR for a Data Plane API.
Click here to open a PR for a Control Plane (ARM) API.

No API change.
Only change is to JSON examples.
So there is no custom impact.


Rely on the git module instead of CDN?

Right now, the editor element is powered by the JS script loaded from the Internet. Maybe it'll be more reliable if we use Ace sources as nx-ace submodule?
Am I being over-paranoid?

Agreed! You are not being over-paranoid.


Added c++ solution of Leetcode Problem  #477

Pull Request Template
What have you Changed(must)
Added C++ Solution for Problem no 477(Total Hamming Distance) of Leetcode
Issue no.(must) - #125
Pr will be close and marked as spam. If issue number not found or issue was assigned to someone else.
Marking as spam can block your account from HacktoberFest.
Self Check(Tick After Making pull Request)

[x] This issue was assigned to me if not it will marked as spam.
[x] My file is in proper folder
[x] I am following clean code and Documentation.
[x] I have added title and what program will do first in the file
[x] I have named the file as (Problem #). (Problem Title(in Camel Case)).(extension)
ex. 2. AddToNumbers.py

README - How to Contribute

Added Issue number @SSKale1


Configure correct permissions in the recipevault repo

Configure Branch Protection Rules - Add rule to require a PR before merging to main.
Require status checks to pass before merging - The application should pass testing before being merged.

waiting to create checks in the CI pipeline so this can be closed


Revert "buildenv: read propagated-user-env-packages line-by-line"

This reverts commit dce958ac396e88c09d5b19c284f41eef68f54ce7.
Motivation for this change
This change was originally a fix for https://github.com/NixOS/nixpkgs/commit/3cb745d5a69018829ac15f7d5a508135f6bda123 which was reverted in https://github.com/NixOS/nixpkgs/commit/b087618ac06256cb3c06278e7eaba45841f4ea91
Since the revert https://github.com/NixOS/nixpkgs/commit/dce958ac396e88c09d5b19c284f41eef68f54ce7 breaks Qt applications.
I don't know if this is the correct fix or if https://github.com/NixOS/nixpkgs/commit/3cb745d5a69018829ac15f7d5a508135f6bda123 should be reinstated, the commit message in the revert made me lean towards just restoring the old behaviour.
Either solution would work fine, I have tested both.
If that solution is preferable I can close this one and create a new PR.
Things done
Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers.

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc @ttuegel

@adisbladis I think you are correct that this should be reverted. Note that this needs to go in staging instead.

ping @Ericson2314

Please do NOT merge and wait for @Ericson2314's reply :)

Ah thanks. I forgot that @ttuegel fixed my earlier change here when I rolled it back.
I think it would be better to continue reading the entire file while splitting on newline and space alike. See https://github.com/NixOS/nix/pull/1482 for how that's done in Perl. The reason for this is other code (e.g. https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L309) reads the entire file (even before any of my changes).
[In https://github.com/NixOS/nixpkgs/pull/27427#issuecomment-318737198, @oxij proposes that we switch to \0 delimiting, which is most robust. But we can still do with that transition strategy: if the file contains null bytes, splt on those, else split on all white-space as I describe above.]
@edolstra Any opinions? Not quite sure where you stand from the Nix PRs.

It's good to come up with a long-term solution, but if that takes time I prefer we roll back as soon as possible and fix issues for our users. We can come up with a long-term solution later.

I just pinged @edolstra on IRC. Happy to merge this for now if I don't get a response today.


Uncaught TypeError: Cannot read property 'getAttribute' of undefined

[Enter steps to reproduce:]

Right click a project and click edit
Changed the colour and clicked update and then the error was fired

Atom: 1.14.2 x64
Electron: 1.3.13
OS: Linux Mint
Thrown From: project-viewer package 1.0.7
User: root
Stack Trace
Uncaught TypeError: Cannot read property 'getAttribute' of undefined
At /root/.atom/packages/project-viewer/src/editor-view.js:26

TypeError: Cannot read property 'getAttribute' of undefined
    at /packages/project-viewer/src/editor-view.js:26:39)
    at /packages/project-viewer/src/editor-view.js:707:24)

Commands
     -2:36.1.0 project-viewer:migrate03x (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
  2x -2:21.4.0 project-viewer:createGroupOrProject (ul.background-message.centered)
     -0:29.6.0 project-viewer:openEditor (div.list-item)

Non-Core Packages
atom-lorempixel 0.1.0
context-git 0.15.0
emmet 2.4.3
git-diff-details 1.4.0
git-status 0.3.4
git-time-machine 1.5.6
lorem-insults 0.1.0
markdown-preview-plus 2.4.2
markdown-scroll-sync 2.1.2
project-viewer 1.0.7
Remote-FTP 0.10.5
simple-drag-drop-text 0.3.4
sync-settings 0.8.1
tree-view-git-branch 0.1.2
tree-view-git-status 1.3.0

messed up here. wait for next release please

@siteleas, can you please validate again? thanks


Ship default config file

It would be useful to write and maintain a default configuration file that gets included in the release zip file and installed in the right place for .deb files.
This default config file would have all the default values, commented out. Preferably with some comment describing what it does. For instance;
enable pruning by setting a size, in megabytes, that is the maximum the blockchain-database should get.
#prune = 0

Fixed this. 1.2 shipped this.


Documentation issue: Progression migration

On http://bluebirdjs.com/docs/api/progression-migration.html, the link in this paragraph leads to a 404 error page:

For old code that still uses it, see the progression docs in the deprecated API documentation.

Thanks, will be fixed on next rebuild of the docs.

Awesome :) :+1:


Detected code that calls async_forward_entry_setup will be depreciated

System Health details
System Information

version
core-2024.7.4

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.12.4

os_name
Linux

os_version
6.6.31-haos-raspi

arch
aarch64

timezone
America/New_York

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
4949

Installed Version
1.34.0

Stage
running

Available Repositories
1385

Downloaded Repositories
8

Home Assistant Cloud

logged_in
false

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 12.4

update_channel
stable

supervisor_version
supervisor-2024.06.2

agent_version
1.6.0

docker_version
26.1.4

disk_total
116.7 GB

disk_used
10.7 GB

healthy
true

supported
true

host_connectivity
true

supervisor_connectivity
true

ntp_synchronized
true

virtualization

board
rpi4-64

supervisor_api
ok

version_api
ok

installed_addons
Samba share (12.3.2), Duck DNS (1.18.0), Studio Code Server (5.15.0), Advanced SSH & Web Terminal (18.0.0), InfluxDB (5.0.0), Home Assistant Google Drive Backup (0.112.1), Whisper (2.1.2), AdGuard Home (5.1.1), Matter Server (6.3.1), Mosquitto broker (6.4.1), Tailscale (0.21.0)

Dashboards

dashboards
3

resources
0

views
2

mode
storage

Recorder

oldest_recorder_run
July 30, 2024 at 8:54 PM

current_recorder_run
August 3, 2024 at 10:36 AM

estimated_db_size
103.77 MiB

database_engine
sqlite

database_version
3.45.3

Checklist

[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of currently previous issues..

Describe the issue
Depreciated code ending in 2025.1
Detected code that calls async_forward_entry_setup will be depreciated
Reproduction steps
1.error in logs
2.
3.
...
Debug logs
2024-08-03 10:49:04.867 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration linktap which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-08-03 10:49:04.869 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration rpi_gpio which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-08-03 10:49:04.870 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration traeger which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-08-03 10:49:04.872 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration kidde which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-08-03 10:49:04.873 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration aarlo which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-08-03 10:49:04.875 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-08-03 10:49:19.104 INFO (MainThread) [custom_components.traeger]
-------------------------------------------------------------------
Traeger
Version: 2024.04.14
This is a custom integration!
If you have any issues with this you need to open an issue here:
https://github.com/njobrien1006/hass_traeger/issues
-------------------------------------------------------------------

2024-08-03 10:49:19.104 INFO (MainThread) [custom_components.traeger] do_cognito t:2024-08-03 14:49:19.104845
2024-08-03 10:49:19.107 INFO (MainThread) [custom_components.traeger] do_cognito amzdate:20240803T144919Z
2024-08-03 10:49:19.107 INFO (MainThread) [custom_components.traeger] do_cognito<EMAIL_ADDRESS>2024-08-03 10:49:19.107 INFO (MainThread) [custom_components.traeger] do_cognito CLIENT_ID:2fuohjtqv1e63dckp5v84rau0j
2024-08-03 10:49:20.132 INFO (MainThread) [custom_components.traeger] Call_Later in: 30 seconds.
2024-08-03 10:49:20.144 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'traeger' calls async_forward_entry_setup for integration, traeger with title<EMAIL_ADDRESS>and entry_id: b126adef385ebff0784a60ac42cd1c1b, which is deprecated and will stop working in Home Assistant 2025.6, await async_forward_entry_setups instead at custom_components/traeger/__init__.py, line 48: hass.async_create_task(, please create a bug report at https://github.com/njobrien1006/hass_traeger/issues
2024-08-03 10:49:21.586 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'hacs' calls hass.http.register_static_path which is deprecated because it does blocking I/O in the event loop, instead call `await hass.http.async_register_static_paths([StaticPathConfig("/hacsfiles/themes", "/config/themes", True)])`; This function will be removed in 2025.7 at custom_components/hacs/base.py, line 1182: self.hass.http.register_static_path(f"{URL_BASE}/themes", self.hass.config.path("themes")), please create a bug report at https://github.com/hacs/integration/issues
2024-08-03 10:49:21.599 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'hacs' calls hass.http.register_static_path which is deprecated because it does blocking I/O in the event loop, instead call `await hass.http.async_register_static_paths([StaticPathConfig("/hacsfiles/frontend", "/config/custom_components/hacs/hacs_frontend", False)])`; This function will be removed in 2025.7 at custom_components/hacs/frontend.py, line 54: hass.http.register_static_path(f"{URL_BASE}/frontend", locate_dir(), cache_headers=False), please create a bug report at https://github.com/hacs/integration/issues
2024-08-03 10:49:21.610 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'hacs' calls hass.http.register_static_path which is deprecated because it does blocking I/O in the event loop, instead call `await hass.http.async_register_static_paths([StaticPathConfig("/hacsfiles/iconset.js", "/config/custom_components/hacs/iconset.js", True)])`; This function will be removed in 2025.7 at custom_components/hacs/frontend.py, line 57: hass.http.register_static_path(, please create a bug report at https://github.com/hacs/integration/issues
2024-08-03 10:49:21.620 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'hacs' accesses hass.components.frontend. This is deprecated and will stop working in Home Assistant 2024.9, it should be updated to import functions used from frontend directly at custom_components/hacs/frontend.py, line 68: hass.components.frontend.async_register_built_in_panel(, please create a bug report at https://github.com/hacs/integration/issues
2024-08-03 10:49:23.671 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that calls async_forward_entry_setup for integration traeger with title<EMAIL_ADDRESS>and entry_id: b126adef385ebff0784a60ac42cd1c1b, during setup without awaiting async_forward_entry_setup, which can cause the setup lock to be released before the setup is done. This will stop working in Home Assistant 2025.1. Please report this issue.
Stack (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
    sys.exit(main())
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
    exit_code = runner.run(runtime_conf)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run
    return loop.run_until_complete(setup_and_run_hass(runtime_config))
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
    self.run_forever()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
    self._run_once()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once
    handle._run()
  File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 2122, in async_forward_entry_setup
    _report_non_awaited_platform_forwards(entry, "async_forward_entry_setup")
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1175, in _report_non_awaited_platform_forwards
    report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 151, in report
    _LOGGER.warning(msg, stack_info=True)
2024-08-03 10:49:23.681 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that calls async_forward_entry_setup for integration traeger with title<EMAIL_ADDRESS>and entry_id: b126adef385ebff0784a60ac42cd1c1b, during setup without awaiting async_forward_entry_setup, which can cause the setup lock to be released before the setup is done. This will stop working in Home Assistant 2025.1. Please report this issue.
Stack (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
    sys.exit(main())
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
    exit_code = runner.run(runtime_conf)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run
    return loop.run_until_complete(setup_and_run_hass(runtime_config))
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
    self.run_forever()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
    self._run_once()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once
    handle._run()
  File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 2122, in async_forward_entry_setup
    _report_non_awaited_platform_forwards(entry, "async_forward_entry_setup")
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1175, in _report_non_awaited_platform_forwards
    report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 151, in report
    _LOGGER.warning(msg, stack_info=True)
2024-08-03 10:49:23.691 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that calls async_forward_entry_setup for integration traeger with title<EMAIL_ADDRESS>and entry_id: b126adef385ebff0784a60ac42cd1c1b, during setup without awaiting async_forward_entry_setup, which can cause the setup lock to be released before the setup is done. This will stop working in Home Assistant 2025.1. Please report this issue.
Stack (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
    sys.exit(main())
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
    exit_code = runner.run(runtime_conf)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run
    return loop.run_until_complete(setup_and_run_hass(runtime_config))
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
    self.run_forever()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
    self._run_once()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once
    handle._run()
  File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 2122, in async_forward_entry_setup
    _report_non_awaited_platform_forwards(entry, "async_forward_entry_setup")
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1175, in _report_non_awaited_platform_forwards
    report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 151, in report
    _LOGGER.warning(msg, stack_info=True)
2024-08-03 10:49:23.697 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that calls async_forward_entry_setup for integration traeger with title<EMAIL_ADDRESS>and entry_id: b126adef385ebff0784a60ac42cd1c1b, during setup without awaiting async_forward_entry_setup, which can cause the setup lock to be released before the setup is done. This will stop working in Home Assistant 2025.1. Please report this issue.
Stack (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
    sys.exit(main())
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
    exit_code = runner.run(runtime_conf)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run
    return loop.run_until_complete(setup_and_run_hass(runtime_config))
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
    self.run_forever()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
    self._run_once()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once
    handle._run()
  File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 2122, in async_forward_entry_setup
    _report_non_awaited_platform_forwards(entry, "async_forward_entry_setup")
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1175, in _report_non_awaited_platform_forwards
    report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 151, in report
    _LOGGER.warning(msg, stack_info=True)
2024-08-03 10:49:23.702 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that calls async_forward_entry_setup for integration traeger with title<EMAIL_ADDRESS>and entry_id: b126adef385ebff0784a60ac42cd1c1b, during setup without awaiting async_forward_entry_setup, which can cause the setup lock to be released before the setup is done. This will stop working in Home Assistant 2025.1. Please report this issue.
Stack (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
    sys.exit(main())
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
    exit_code = runner.run(runtime_conf)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run
    return loop.run_until_complete(setup_and_run_hass(runtime_config))
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
    self.run_forever()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
    self._run_once()
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1990, in _run_once
    handle._run()
  File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 2122, in async_forward_entry_setup
    _report_non_awaited_platform_forwards(entry, "async_forward_entry_setup")
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1175, in _report_non_awaited_platform_forwards
    report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 151, in report
    _LOGGER.warning(msg, stack_info=True)
2024-08-03 10:49:23.765 WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.co_level (<class 'custom_components.kidde.sensor.KiddeSensorEntity'>) is using native unit of measurement 'None' which is not a valid unit for the device class ('carbon_monoxide') it is using; expected one of ['ppm']; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/tache/homeassistant-kidde/issues
2024-08-03 10:49:23.768 WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.battery_state (<class 'custom_components.kidde.sensor.KiddeSensorEntity'>) is using state class 'measurement' which is impossible considering device class ('enum') it is using; expected None; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/tache/homeassistant-kidde/issues
2024-08-03 10:49:23.770 ERROR (MainThread) [homeassistant.components.sensor] Error adding entity None for domain sensor with platform kidde
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 598, in _async_add_entities
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 717, in _async_add_entity
    entity.add_to_platform_start(
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 244, in add_to_platform_start
    self._sensor_option_unit_of_measurement = self._get_initial_suggested_unit()
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 399, in _get_initial_suggested_unit
    self.device_class, self.native_unit_of_measurement
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/kidde/sensor.py", line 206, in native_unit_of_measurement
    match self.kidde_device.get(self.entity_description.key).get("Unit").upper():
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'str' object has no attribute 'get'
2024-08-03 10:49:30.858 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'hacs' accesses hass.helpers.event. This is deprecated and will stop working in Home Assistant 2024.11, it should be updated to import functions used from event directly at custom_components/hacs/base.py, line 630: self.hass.helpers.event.async_track_time_interval(, please create a bug report at https://github.com/hacs/integration/issues
2024-08-03 10:49:50.136 DEBUG (MainThread) [custom_components.traeger] @Call_Later SyncMain CreatingTask for async Main.
2024-08-03 10:49:50.137 DEBUG (MainThread) [custom_components.traeger] Current Main Loop Time:<PHONE_NUMBER>.1372926
2024-08-03 10:49:50.140 DEBUG (MainThread) [custom_components.traeger] MQTT Logger Token Time Remaining:3568.9638392925262 MQTT Time Remaining:-31.036202430725098
2024-08-03 10:49:50.806 DEBUG (MainThread) [custom_components.traeger] MQTT URL:wss://aqmix2am7g1w-ats.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAYCV2Q4WGKNIL76UP%2F20240803%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20240803T144950Z&X-Amz-SignedHeaders=host&X-Amz-Signature=995689464d7a4f7d68d7a8b11236db9a66c49b16bcb4f1d8877f8659a05d7cea&X-Amz-Security-Token=FwoGZXIvYXdzEND%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaDHq%2FpMKtDFSA3quJAiL2As9meGY7Hw%2FSU1AEocOyNWEQmbTfFP%2BPgbLEcqR62NZtwsM7bxIvyO50iJj2iYyZ0pXV3AGJoOiJBJD9nOa4xlskYkxp0TAwIsdiVClzsnIYTI0cOyyCmDHDRK0ceuqP90psjXV5T4bmwNK9CJkwWAv6krRZjuYE7n0nEfmRpQ%2Bpm%2BoUlyyAyqWWb4wSGuGY9TcYAu4fjypjMrE2DsKQNVLM1j1mkjhCSaZR0RJuF3DuPtgcWXi93kNwj6BElPB62TvaIcazvT5Updfct4sHDNbk2mwrlZMO7WwDp1Fab331fQOv%2FlG5%2BhmxvAJskH4GVp6BhkUM5pOCG3rs4agEbtGzycrugWhy9xffqapCRFbk19mO7SbuJtapMMwqz5%2FjzOTqUUAOjfbgj12eWvNfq%2BhmaOlu9Q0ZttZjQ9qixBwotlehBaFqEM3PBOXr72wnuESrkaYTotd%2F6ByRWZcUnlryPLLYx6n5FpVEU9BcWeSNwpXOM0GxKI6HubUGMi2DdnIpaOM6TMSwPtS9MKLgBJk3IhuTzqe5yENMNPs0HvJvJdriBJlpxJYilBM%3D Expires @:1722700190.1412048
2024-08-03 10:49:50.808 INFO (MainThread) [custom_components.traeger] Thread Active Count:25
2024-08-03 10:49:51.166 DEBUG (MainThread) [custom_components.traeger] Sock.Open.Report...Client: <paho.mqtt.client.Client object at 0x7f791bc980> UserData: None Sock: <paho.mqtt.client.WebsocketWrapper object at 0x7f706b4110>
2024-08-03 10:49:51.166 DEBUG (MainThread) [custom_components.traeger] Sending CONNECT (u0, p0, wr0, wq0, wf0, c1, k300) client_id=b''
2024-08-03 10:49:51.166 DEBUG (MainThread) [custom_components.traeger] Sock.Regi.Write....Client: <paho.mqtt.client.Client object at 0x7f791bc980> UserData: None Sock: <paho.mqtt.client.WebsocketWrapper object at 0x7f706b4110>
2024-08-03 10:49:51.167 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Start MQTT Loop Forever
2024-08-03 10:49:51.169 DEBUG (MainThread) [custom_components.traeger] Call_Later @:<PHONE_NUMBER>.1412048
2024-08-03 10:49:51.169 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Sock.UnRg.Write....Client: <paho.mqtt.client.Client object at 0x7f791bc980> UserData: None Sock: <paho.mqtt.client.WebsocketWrapper object at 0x7f706b4110>
2024-08-03 10:49:51.260 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Received CONNACK (0, 0)
2024-08-03 10:49:51.260 INFO (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Grill Connected
2024-08-03 10:49:51.261 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Sending SUBSCRIBE (d0, m1) [(b'prod/thing/update/E8EB1B442EDF', 1)]
2024-08-03 10:49:51.261 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Sock.Regi.Write....Client: <paho.mqtt.client.Client object at 0x7f791bc980> UserData: None Sock: <paho.mqtt.client.WebsocketWrapper object at 0x7f706b4110>
2024-08-03 10:49:51.263 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Sock.UnRg.Write....Client: <paho.mqtt.client.Client object at 0x7f791bc980> UserData: None Sock: <paho.mqtt.client.WebsocketWrapper object at 0x7f706b4110>
2024-08-03 10:49:51.367 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Received SUBACK
2024-08-03 10:49:51.367 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] OnSubscribe Callback. Client:<paho.mqtt.client.Client object at 0x7f791bc980> userdata:None mid:1 granted_qos:(1,)
2024-08-03 10:49:51.371 DEBUG (MainThread) [custom_components.traeger] Send Command Topic: E8EB1B442EDF, Send Command: 90
2024-08-03 10:49:51.456 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Received PUBLISH (d0, q0, r0, m0), 'prod/thing/update/E8EB1B442EDF', ...  (2385 bytes)
2024-08-03 10:49:51.457 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] grill_message: message.topic = prod/thing/update/E8EB1B442EDF, message.payload = b'{"thingName":"E8EB1B442EDF","jobs":[{"jobId":"Link_Pro575_020205","thingName":"E8EB1B442EDF","currentStatus":{"status":"QUEUED","timestamp":1722534558},"isFinished":false,"isInProgress":true}],"status":{"ambient":101,"connected":false,"cook_id":"","cook_timer_complete":0,"cook_timer_end":0,"cook_timer_start":0,"current_cycle":0,"current_step":0,"errors":0,"grill":94,"in_custom":0,"keepwarm":0,"pellet_level":25,"probe":0,"probe_alarm_fired":0,"probe_con":0,"probe_set":0,"real_time":0,"server_status":0,"set":165,"smoke":0,"sys_timer_complete":1,"sys_timer_end":0,"sys_timer_start":0,"system_status":99,"time":1722113831,"units":1,"acc":[{"uuid":"p0","channel":"p0","type":"probe","con":0,"probe":{"get_temp":0,"set_temp":0,"alarm_fired":0}}]},"features":{"cold_smoke_enabled":0,"grill_mode_enabled":0,"open_loop_mode_enabled":0,"pellet_sensor_connected":1,"pellet_sensor_enabled":1,"super_smoke_enabled":0,"time":1722101351},"limits":{"max_grill_temp":500},"settings":{"config_version":"04.017","device_type_id":2104,"feature":0,"fw_build_num":"20230811.111537","fw_version":"02.02.04","language":0,"rssi":-38,"speaker":1,"ssid":"Sloop-IOT","time":1722104247,"units":1},"usage":{"auger":189910,"cook_cycles":35,"error_stats":{"auger_disco":0,"auger_ovrcur":0,"bad_thermocouple":0,"fan_disco":0,"ign_disco":0,"ignite_fail":0,"low_ambient":0,"lowtemp":0,"overheat":0},"fan":273662,"grease_trap_clean_countdown":0,"grill_clean_countdown":0,"hotrod":90698,"runtime":274249,"time":1722109624},"custom_cook":{"cook_cycles":[{"cycle_name":"Chicken Challenge","populated":1,"num_steps":1,"units":1,"slot_num":0,"steps":[{"probe_set_temp":170,"time_set":0,"keepwarm":0,"smoke":0,"step_num":1,"set_temp":425,"use_timer":0}]},{"cycle_name":"Beginner\'s Brisket","populated":1,"num_steps":2,"units":1,"slot_num":1,"steps":[{"probe_set_temp":0,"time_set":12600,"keepwarm":0,"smoke":0,"step_num":1,"set_temp":165,"use_timer":1},{"probe_set_temp":190,"time_set":0,"keepwarm":0,"smoke":0,"step_num":2,"set_temp":225,"use_timer":0}]},{"slot_num":2,"populated":0},{"slot_num":3,"populated":0},{"slot_num":4,"populated":0}]},"details":{"thingName":"E8EB1B442EDF","userId":"2ea04711-b2d5-454c-a171-b91acd113dad","lastConnectedOn":1722101349,"thingNameLower":"e8eb1b442edf","friendlyName":"TRAEGER PRO 575","lat":39.881571,"long":-75.422951,"deviceType":"2104"},"stateIndex":31659,"schemaVersion":"1.0"}'
2024-08-03 10:49:51.457 INFO (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Token Time Remaining:3567.646888256073 MQTT Time Remaining:3598.6834378242493
2024-08-03 10:49:51.479 DEBUG (MainThread) [custom_components.traeger] CookCycle Steps:[]
2024-08-03 10:49:51.966 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Received PUBLISH (d0, q0, r0, m0), 'prod/thing/update/E8EB1B442EDF', ...  (2385 bytes)
2024-08-03 10:49:51.967 DEBUG (Thread-11 (mqtt_connect_func)) [custom_components.traeger] grill_message: message.topic = prod/thing/update/E8EB1B442EDF, message.payload = b'{"thingName":"E8EB1B442EDF","jobs":[{"jobId":"Link_Pro575_020205","thingName":"E8EB1B442EDF","currentStatus":{"status":"QUEUED","timestamp":1722534558},"isFinished":false,"isInProgress":true}],"status":{"ambient":101,"connected":false,"cook_id":"","cook_timer_complete":0,"cook_timer_end":0,"cook_timer_start":0,"current_cycle":0,"current_step":0,"errors":0,"grill":94,"in_custom":0,"keepwarm":0,"pellet_level":25,"probe":0,"probe_alarm_fired":0,"probe_con":0,"probe_set":0,"real_time":0,"server_status":0,"set":165,"smoke":0,"sys_timer_complete":1,"sys_timer_end":0,"sys_timer_start":0,"system_status":99,"time":1722113831,"units":1,"acc":[{"uuid":"p0","channel":"p0","type":"probe","con":0,"probe":{"get_temp":0,"set_temp":0,"alarm_fired":0}}]},"features":{"cold_smoke_enabled":0,"grill_mode_enabled":0,"open_loop_mode_enabled":0,"pellet_sensor_connected":1,"pellet_sensor_enabled":1,"super_smoke_enabled":0,"time":1722101351},"limits":{"max_grill_temp":500},"settings":{"config_version":"04.017","device_type_id":2104,"feature":0,"fw_build_num":"20230811.111537","fw_version":"02.02.04","language":0,"rssi":-38,"speaker":1,"ssid":"Sloop-IOT","time":1722104247,"units":1},"usage":{"auger":189910,"cook_cycles":35,"error_stats":{"auger_disco":0,"auger_ovrcur":0,"bad_thermocouple":0,"fan_disco":0,"ign_disco":0,"ignite_fail":0,"low_ambient":0,"lowtemp":0,"overheat":0},"fan":273662,"grease_trap_clean_countdown":0,"grill_clean_countdown":0,"hotrod":90698,"runtime":274249,"time":1722109624},"custom_cook":{"cook_cycles":[{"cycle_name":"Chicken Challenge","populated":1,"num_steps":1,"units":1,"slot_num":0,"steps":[{"probe_set_temp":170,"time_set":0,"keepwarm":0,"smoke":0,"step_num":1,"set_temp":425,"use_timer":0}]},{"cycle_name":"Beginner\'s Brisket","populated":1,"num_steps":2,"units":1,"slot_num":1,"steps":[{"probe_set_temp":0,"time_set":12600,"keepwarm":0,"smoke":0,"step_num":1,"set_temp":165,"use_timer":1},{"probe_set_temp":190,"time_set":0,"keepwarm":0,"smoke":0,"step_num":2,"set_temp":225,"use_timer":0}]},{"slot_num":2,"populated":0},{"slot_num":3,"populated":0},{"slot_num":4,"populated":0}]},"details":{"thingName":"E8EB1B442EDF","userId":"2ea04711-b2d5-454c-a171-b91acd113dad","lastConnectedOn":1722101349,"thingNameLower":"e8eb1b442edf","friendlyName":"TRAEGER PRO 575","lat":39.881571,"long":-75.422951,"deviceType":"2104"},"stateIndex":31659,"schemaVersion":"1.0"}'
2024-08-03 10:49:51.967 INFO (Thread-11 (mqtt_connect_func)) [custom_components.traeger] Token Time Remaining:3567.137107849121 MQTT Time Remaining:3598.1736578941345
2024-08-03 10:49:51.976 DEBUG (MainThread) [custom_components.traeger] CookCycle Steps:[]

Looks to be just another home assistant deprecation. Will address in next release. Currently is not a breaking error.


Fix Triton mini batch bug

Fixes issue that can occur when the number of input tensors is greater than the number of rows in the dataframe.
Refactor the on_next method of the InferenceClientStage which was getting a bit long and hard to follow, moving some logic to their own methods.
Wait until all mini-batches have returned before calculating the reduction.

Fixes #680

PR #667 contained this code and was merged.


Pre Go Live: Redirects / Sitemap.xml / Robots.txt

Legacy Redirects
In most migrations there are legacy URLs that are retired. Make sure those are reflected in your redirects spreadsheet (redirects.xlsx in sharepoint or redirects in google), found in your project content folder.
Sitemap & Robots
For most websites with a significant number of pages, a sitemap is desirable. Franklin automatically generates those from the query index. See here for more information on how to set up a query index.
If you have a sitemap that’s generated for your site make sure it is discoverable from your robots.txt.
Note: hlx.page and hlx.live are kept hidden from crawlers intentionally, to avoid duplicate content.
Source

Sitemap created for blogs under /blog/sitemap.xml
It still needs to be added to the robots.txt on the original merative.com AEM CS code

Open item to remove nav and footer from sitemap.xml.

move nav and footer to separate folder
update blog-index to exclude that folder
everything will flow correctly after that.

robots.txt updated for merative main site to add the merative.com/blog sitemap.


BUG: (at least on Android) RN-app crashes, freezes or loses connection to development server when device is roaming and roaming is disabled on device

Is this a bug report?
Yes
Have you read the Bugs section of the How to Contribute guide?
Yes
Environment
react-native-cli: 2.0.1
react-native: 0.46.2 (tested on 0.44.0 too)
node: 8.2.0
npm -v

Target Platform: Android
Development Operating System: Windows 10
Build tools: Only Android emulators relevant for this bug (tested on 7.1.1 x86 and 6.0 x86)

Steps to Reproduce

Create new RN-project
Run it on Android emulator (not sure if same problem happens on iOS, haven't had the opportunity to test)
Test it responds correctly (double-R pretty much proves the app is working fine, buttons that do something are also viable testers)
Go to the phone's settings and make sure Roaming is turned off
Emulate roaming on the emulator (0.44.0 might crash at this point)
Go to the app an try reloading (is either frozen and does nothing or informs that there is no connection to development server)
If you get the red error screen and the app is not crashed/frozen you can set the emulator's data status back to 'Home' or enable roaming again and double-R will work again.

Expected Behavior
Roaming should just cut the connection if roaming is disabled. Although listening to connection on a native Android app (with roaming disabled) going from connected state to roaming just returns disconnected, but going from disconnected state to roaming makes the connection awkwardly connect and disconnect again, but nothing bad happens to the native app itself.
Native app tested with the code below:
`private class ConnectionChangeReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        ConnectivityManager connectivityManager = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
        NetworkInfo activeNetwork = connectivityManager.getActiveNetworkInfo();
        //from connected state to roaming returns 'false'
        //from disconnected state to roaming returns first 'true' and then runs again with 'false'
        System.out.println(activeNetwork != null && activeNetwork.isConnected());
    }
}`

Actual Behavior
At first I tested this bug on a 0.44.0 app with self-made native Android ConnectionChangeListener partially shown above. Every other connection change did what expected (emitted custom event through DeviceEventEmitter and brought up a popup on disconnect and made it disappear on connect) but roaming with roaming disabled has made the app freeze (completely unresponsive to any click, Ctrl+M or double-R) or crashed it completely.
Thought it was the listeners fault at first but after some digging I thought it might be a problem with just RN. After that I created a new project with 'react-native init'-command (having global version 0.46.2 so this test is with that) ran it and emulated roaming. The app doesn't crash or freeze, but on reload throws the red screen with 'Could not connect to development server'-error.

i have this question too


Excel changes

Improves excel performance 332.46s for old implementation vs 232.18s in new implementation for 90MB excel file.

Attaches tqdm progressbar if the file was saved in such a way that openpyxl manages to infer the sheet size when opened.

I'm just not sure if the implementation is not too convoluted. It's an improvement I guess but it's still too slow for my liking but I'm not really sure if I can do much in python.

Codecov Report

Merging #83 (adf357d) into master (1446b17) will increase coverage by 0.08%.
The diff coverage is 94.54%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
@@            Coverage Diff             @@
##           master      #83      +/-   ##
==========================================
+ Coverage   89.39%   89.48%   +0.08%
==========================================
  Files          49       49
  Lines        6763     6848      +85
==========================================
+ Hits         6046     6128      +82
- Misses        717      720       +3

Flag
Coverage Δ

pytest
89.48% <94.54%> (+0.08%)
:arrow_up:

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

Files Changed
Coverage Δ

tablite/core.py
86.58% <ø> (ø)

tablite/import_utils.py
80.69% <94.54%> (+3.56%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Helm deployment stuck in the init state

Describe the bug
When deploying the helm chart for Mayastor v2.0.0 the pods are stuck in the init state.
To Reproduce
Steps to reproduce the behavior:
On a fresh k8s cluster I am deploying the helm chart:
kubectl label node worker-node01 openebs.io/engine=mayastor
kubectl label node worker-node02 openebs.io/engine=mayastor
kubectl label node worker-node03 openebs.io/engine=mayastor
helm repo add mayastor https://openebs.github.io/mayastor-extensions/
helm install mayastor mayastor/mayastor -n mayastor --create-namespace --set="etcd.replicaCount=1,etcd.persistence.storageClass=manual,etcd.livenessProbe.initialDelaySeconds=5,etcd.readinessProbe.initialDelaySeconds=5,loki-stack.loki.persistence.storageClassName=manual,obs.callhome.enabled=false" --version 2.0.0

The Mayastor pods are stuck in the init state:
vagrant@master-node:~/testfiles/mayastor$ kubectl get pods -n mayastor
NAME                                          READY   STATUS     RESTARTS   AGE
mayastor-agent-core-557c9c5cc8-rdwqz          0/2     Init:0/1   0          5m43s
mayastor-agent-ha-node-c5ltp                  0/1     Init:0/1   0          5m43s
mayastor-agent-ha-node-gdqn7                  0/1     Init:0/1   0          5m43s
mayastor-agent-ha-node-hnbch                  0/1     Init:0/1   0          5m43s
mayastor-api-rest-744d4c7f5-nb8gc             0/1     Init:0/2   0          5m43s
mayastor-csi-controller-8688994959-j2kqp      0/3     Init:0/1   0          5m43s
mayastor-csi-node-7qmzj                       2/2     Running    0          5m43s
mayastor-csi-node-m52z7                       2/2     Running    0          5m43s
mayastor-csi-node-qs75w                       2/2     Running    0          5m43s
mayastor-etcd-0                               1/1     Running    0          5m43s
mayastor-io-engine-24vgl                      0/2     Init:0/2   0          5m43s
mayastor-io-engine-5kv4f                      0/2     Init:0/2   0          5m43s
mayastor-io-engine-nd2jd                      0/2     Init:0/2   0          5m43s
mayastor-loki-0                               1/1     Running    0          5m43s
mayastor-operator-diskpool-7975bb4b85-j6kwr   0/1     Init:0/2   0          5m43s
mayastor-promtail-f6zmp                       1/1     Running    0          5m43s
mayastor-promtail-m7zt8                       1/1     Running    0          5m43s
mayastor-promtail-zbcv6                       1/1     Running    0          5m43s

Expected behavior
I would expect all mayastor pods to be running after about 3 min.
OS info

Distro: Debian 11
Kernel version 5.19.0
MayaStor v2.0.0

Additional context
The following helm install worked for me a few days ago:
helm install mayastor mayastor/mayastor -n mayastor --create-namespace --set="etcd.replicaCount=1,etcd.persistence.storageClass=manual,etcd.livenessProbe.initialDelaySeconds=5,etcd.readinessProbe.initialDelaySeconds=5,loki-stack.loki.persistence.storageClassName=manual" --version 2.0.0-rc.2

Hi @MaisenbacherD seems like the pods are waiting on the init-containers, most of the pods wait on the mayastor-agent-core to come up first. Can you please check the why the mayastor-agent-core init container is struck?

Hi @Abhinandan-Purkait,
Sure here the describe:
vagrant@master-node:~/testfiles/mayastor$ kubectl describe pod mayastor-agent-core-557c9c5cc8-rdwqz -n mayastor
Name:                 mayastor-agent-core-557c9c5cc8-rdwqz
Namespace:            mayastor
Priority:<PHONE_NUMBER>
Priority Class Name:  system-cluster-critical
Service Account:      mayastor-service-account
Node:                 worker-node02/<IP_ADDRESS>
Start Time:           Thu, 09 Feb 2023 14:14:11 +0000
Labels:               app=agent-core
                      openebs.io/logging=true
                      openebs.io/release=mayastor
                      openebs.io/version=2.0.0
                      pod-template-hash=557c9c5cc8
Annotations:          <none>
Status:               Pending
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/mayastor-agent-core-557c9c5cc8
Init Containers:
  etcd-probe:
    Container ID:  containerd://103561668daee0f8307325343a2e3f72153a693b0c0ba2b8e27cd4c5ec0447d6
    Image:         busybox:latest
    Image ID:      docker.io/library/busybox@sha256:7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
      trap "exit 1" TERM; until nc -vzw 5 mayastor-etcd 2379; do date; echo "Waiting for etcd..."; sleep 1; done;
    State:          Running
      Started:      Thu, 09 Feb 2023 14:14:13 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-hrpq8 (ro)
Containers:
  agent-core:
    Container ID:
    Image:         docker.io/openebs/mayastor-agent-core:v2.0.0
    Image ID:
    Port:          50051/TCP
    Host Port:     0/TCP
    Args:
      -smayastor-etcd:2379
      --request-timeout=5s
      --cache-period=30s
      --grpc-server-addr=<IP_ADDRESS>:50051
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  128Mi
    Requests:
      cpu:     500m
      memory:  32Mi
    Environment:
      RUST_LOG:          info
      MY_POD_NAME:       mayastor-agent-core-557c9c5cc8-rdwqz (v1:metadata.name)
      MY_POD_NAMESPACE:  mayastor (v1:metadata.namespace)
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-hrpq8 (ro)
  agent-ha-cluster:
    Container ID:
    Image:         docker.io/openebs/mayastor-agent-ha-cluster:v2.0.0
    Image ID:
    Port:          50052/TCP
    Host Port:     0/TCP
    Args:
      -g=<IP_ADDRESS>:50052
      --store=http://mayastor-etcd:2379
      --core-grpc=https://mayastor-agent-core:50051
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Limits:
      cpu:     100m
      memory:  64Mi
    Requests:
      cpu:     100m
      memory:  16Mi
    Environment:
      RUST_LOG:          info
      MY_POD_NAME:       mayastor-agent-core-557c9c5cc8-rdwqz (v1:metadata.name)
      MY_POD_NAMESPACE:  mayastor (v1:metadata.namespace)
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-hrpq8 (ro)
Conditions:
  Type              Status
  Initialized       False
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kube-api-access-hrpq8:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              kubernetes.io/arch=amd64
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 5s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 5s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  26m   default-scheduler  Successfully assigned mayastor/mayastor-agent-core-557c9c5cc8-rdwqz to worker-node02
  Normal  Pulling    26m   kubelet            Pulling image "busybox:latest"
  Normal  Pulled     26m   kubelet            Successfully pulled image "busybox:latest" in 758.912427ms
  Normal  Created    26m   kubelet            Created container etcd-probe
  Normal  Started    26m   kubelet            Started container etcd-probe

and here the log of the init container:
vagrant@master-node:~/testfiles/mayastor$ kubectl logs mayastor-agent-core-557c9c5cc8-rdwqz -c etcd-probe -n mayastor
nc: bad address 'mayastor-etcd'
Thu Feb  9 14:14:33 UTC 2023
Waiting for etcd...
...

Looks like mayastor-etcd is expected to be running but mayastor-etcd-0 is actually running.

Yeah, its waiting on mayastor-etcd. Can you check kubectl get endpoints -n mayastor, just to check the svc is created properly?

I restarted both coredns pods and the mayastor-agent-core respectively with the command
kubectl get pod mayastor-agent-core-557c9c5cc8-rdwqz -n mayastor -o yaml | kubectl replace --force -f -

Nothing changed and the mayastor-agent-core is still waiting for the init container.
If it helps I can point you to my scripted cluster setup :)
What distro are you testing on?

Yeah, that would help. We only test on Ubuntu and NixOS. cc @tiagolobocastro @blaisedias Please, correct me if I am wrong here.

This is the repo for my kluster setup https://github.com/MaisenbacherD/kubeadm-scripts/tree/wip-libvirsh-setup
You would have to go through "Prerequisites" and "Setup" in the README.md :)
Note that this spins up 4 VMs - a master node and 3 worker nodes. You might need to adjust the resources depending on the machine you are planing to use: https://github.com/MaisenbacherD/kubeadm-scripts/blob/wip-libvirsh-setup/Vagrantfile#L50
Let me know if I can help you somehow or you run into issues :)

@MaisenbacherD Can you test whether the following helps you? something similar happened in microk8s, due to calico vxlan bug. Please try this and let us know.
https://github.com/canonical/microk8s/issues/3695
microk8s kubectl patch felixconfigurations default --patch '{"spec":{"featureDetectOverride":"ChecksumOffloadBroken=true"}}' --type=merge

had the same issue without calico.
one of the maya containers is using host network, so its using the public host ip to contact coredns,
which i didn't anticipate in my network setup.


Bug: Localy added versions with , in name are listed as multiple versions.

When local version (at least of java candidate) is added with version containing symbol , it is then listed as two separate candidates and can be uninstalled only with correct name containing ,.
To reproduce
sdk install java CE-<IP_ADDRESS>,-8 <local path>
sdk list java
Lists as:
 Unclassified  |     | CE           | none    | local only | CE-<IP_ADDRESS>
               |     |              | none    | local only | -8

System info
OS: Linux
bash --version: GNU bash, verze 5.0.17(1)-release (x86_64-pc-linux-gnu)
sdk v: SDKMAN 5.11.2+698

Hi @Ondrej-Douda,
interestingly, the local installation itself seems to be working fine

I'll have a look at it.

uninstall seems to be working fine

So it seems to be a problem with the list view only.

Ah okay, now I understand. The CLI sends the list of locally installed versions to the server, as a comma-separated list. That way the server can be stateless.
@marc0der Any idea on how to best fix this?


Gitlab service installation fails due to an directory permission error while extracting a tar file

Issue description
Gitlab service installation fails due to an directory permission error while extracting a tar file.
Steps to reproduce

put that into configuration.nix:

services = {
    gitlab = {
      databasePassword = "test";
      secrets = {
        secret = "asrjkwbrewkbfskjdfdsfkjrewbgtregtrenmlgkangösdfsdfsädfsd,fdsfoierg9834g3l";
	db = "ewrwerewrwekjbrasbdfkdsfbsdgmfdlhgfhtrihtrotigfhdöhgfhjöfgabfsabfwafawbfesgs";
	otp = "resfrsefj8432t58439t983ngdsfngdfogndgnfdiogadpomcvnbövcpnpbvnxün<üfnüernhpjnh";
      };
      enable = true;
      host = "nixos";
      port = 80;

    };
}

run sudo nixos-rebuild switch
result:

building Nix...
building the system configuration...
these derivations will be built:
  /nix/store/qsb2mrhfdyjw7830mfdzi8nbrbc66d8x-gitlab-8.17.6.drv
  /nix/store/pamzcbxfk9ndvcy2f18alppz9hgcmb2w-gitlab-rake.drv
  /nix/store/h97c0csy14yakzpy138hfn9w8mpz4pbn-system-path.drv
  /nix/store/2a4q9bp2v5i83b3rqz771cmmm2byi7qs-unit-polkit.service.drv
  /nix/store/5sw9plkym0fxbsj8gpbhmpdrsbdf43cp-unit-systemd-fsck-.service.drv
  /nix/store/nlxaxs4vl4r71m79c1l949ahcvzq4w1v-dbus-1.drv
  /nix/store/j9f17jz73zsfs234j5h08ps4fwz7qldb-unit-dbus.service.drv
  /nix/store/nvfd8mhpa2y7db4ps4pi02m9ng3jjjbk-unit-gitlab-workhorse.service.drv
  /nix/store/fcnzg7ss9a1i7cslf0sdxl7v627b8xf7-unit-script.drv
  /nix/store/qy2rndgxrnhg6j7pb22jzwvhlasnj5ma-unit-gitlab.service.drv
  /nix/store/vzw43g2zf6q1cz5mdhph36zyalz5ksch-unit-gitlab-sidekiq.service.drv
  /nix/store/fgxvki4qkzavnfa3vi22n29wrk29vali-system-units.drv
  /nix/store/li02m8n9abdxgvls79zaf61xk54ll4ix-user-units.drv
  /nix/store/2r0pr0h5dqb1by306a5s7p7zz5ic2rnl-etc.drv
  /nix/store/y25ix2vgj0mghi67k9mpr6qgv6kjywsv-nixos-system-nixos-17.03.1775.56da88a298.drv
building path(s) ‘/nix/store/0q16jqsnsgm0pm77p2n4jhbhcnkhs07g-gitlab-8.17.6’
unpacking sources
unpacking source archive /nix/store/lfapnnmck4jg01p89bhzqphvvy8bc1b8-gitlabhq-v8.17.6-src
source root is gitlabhq-v8.17.6-src
patching sources
applying patch /nix/store/7jrncyp165022g49nybb4b03x3gi3f3p-remove-hardcoded-locations.patch
patching file config/environments/production.rb
patching file config/gitlab.yml.example
Hunk #1 succeeded at 512 (offset 36 lines).
patching file config/initializers/1_settings.rb
Hunk #1 succeeded at 201 (offset 9 lines).
Hunk #2 succeeded at 400 (offset 38 lines).
patching file lib/gitlab/logger.rb
patching file lib/gitlab/uploads_transfer.rb
Hunk #1 succeeded at 1 with fuzz 2 (offset -28 lines).
patching file lib/tasks/gitlab/check.rake
applying patch /nix/store/z8ndqjxn7lc8mcmh6i1dxbxn6xav610x-nulladapter.patch
patching file Gemfile
Hunk #1 succeeded at 117 with fuzz 1 (offset -1 lines).
Hunk #2 succeeded at 351 with fuzz 2.
patching file Gemfile.lock
Hunk #2 succeeded at 416 with fuzz 2 (offset 18 lines).
Hunk #3 succeeded at 431 with fuzz 2 (offset 22 lines).
Hunk #4 succeeded at 826 (offset 24 lines).
configuring
no configure script, doing nothing
building
tar: ./opt/gitlab/embedded/bin/ksu: Cannot change mode to rwsr-xr-x: Operation not permitted
tar: Exiting with failure status due to previous errors
dpkg-deb: error: subprocess tar returned error exit status 2
builder for ‘/nix/store/qsb2mrhfdyjw7830mfdzi8nbrbc66d8x-gitlab-8.17.6.drv’ failed with exit code 2
cannot build derivation ‘/nix/store/pamzcbxfk9ndvcy2f18alppz9hgcmb2w-gitlab-rake.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/vzw43g2zf6q1cz5mdhph36zyalz5ksch-unit-gitlab-sidekiq.service.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/nvfd8mhpa2y7db4ps4pi02m9ng3jjjbk-unit-gitlab-workhorse.service.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/qy2rndgxrnhg6j7pb22jzwvhlasnj5ma-unit-gitlab.service.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/h97c0csy14yakzpy138hfn9w8mpz4pbn-system-path.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/fgxvki4qkzavnfa3vi22n29wrk29vali-system-units.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/y25ix2vgj0mghi67k9mpr6qgv6kjywsv-nixos-system-nixos-17.03.1775.56da88a298.drv’: 1 dependencies couldn't be built
error: build of ‘/nix/store/y25ix2vgj0mghi67k9mpr6qgv6kjywsv-nixos-system-nixos-17.03.1775.56da88a298.drv’ failed

Technical details

System: (NixOS: nixos-version, Ubuntu/Fedora: lsb_release -a, ...) 17.03.1775.56da88a298 (Gorilla)
Nix version: (run nix-env --version) nix-env (Nix) 1.11.13
Nixpkgs version: (run nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion) 17.03.1775.56da88a298
Sandboxing enabled: (run grep build-use-sandbox /etc/nix/nix.conf) build-use-sandbox = false

This is already fixed on the 17.03 branch and also doesn't occur anymore on master/17.09 due to the update to gitlab 9


Installing version 7.x or updating from old version

Laravel Version: 7.6
PHP Version: 7.4
Database Driver & Version: pgsql, php7.4-pgsql

Description:
I am trying to set up a new version of Laravel via composer but at last it give me errors:

Class Illuminate\Foundation\ComposerScripts is not autoloadable, can not call post-autoload-dump script.
Script @php artisan package:discover --ansi handling the post-autoload-dump event returned with error code 255.

It was working fine with Laravel 6.x but when I have updated to 7.x it gives me the above errors.
Steps To Reproduce:

Install new version

update class App\Exceptions\Handler also
See: https://laravel.com/docs/7.x/upgrade#symfony-5-related-upgrades

Hi there,
Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!
Thanks.


Login popup window

Description of changes:
This PR addresses comments on #192 and adds options to position the Login Popup window. #192 is a good improvement to the login flow that makes the CCP experience match other 3rd-party login flows, and I think it makes a good addition to the Project.
Since that PR hasn't had any updates in a few months, I'm opening a new PR with the requested changes to try and get this feature into the main library.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Pinged a teammate to review as we need 2 approvals to merge.

Pinged a teammate to review as we need 2 approvals to merge.

Thanks @jolim24601 . I can't request reviewers, so I'm not exactly sure what the steps are from here.

After discussion internally. it would be preferred to keep the old booleans unchanged and add a new options object similar to softphone.
Sorry this is a change from the discussion on #192
Can you please separate these?

Sure thing. If both a loginPopup boolean and a loginWindow options object are supplied, should the options object take precedence over the bool?

I think we can keep it simple and check the old boolean values first followed by the new setting.
loginPopup || loginOptions.usePopup
I changed the names based on my feedback about the naming but feel free to take them or suggest other ones.

@h3adache the update commit restores the boolean behavior of loginPopup and loginPopupAutoClose. It adds an optional loginOptions param that will be ignored if loginPopup is set to false.
From a library user's point of view it makes sense to me that setting loginPopup to false wouldn't open a popup even if I gave an object full of options.

Yea that makes sense to me! We can always push that option to the new options param in future. That's a nice perk of having that separate object 😃

We have a squash and merge procedure that didn't work cleanly with this but your changes are merged.
Thanks you for the contribution @JayWelborn!

Is there a plan to release this to NPM? The current release of v1.5.0 does not include this unfortunately.

@h3adache Is there a plan to release this to NPM? The current release of v1.5.0 does not include this unfortunately.

Hi @tomsabin thanks for the reminder!
Version 1.5.1 is released to NPM now and includes this feature

This no longer functions with 1.6.3 / 1.6.4 and appears to have been reverted with https://github.com/amazon-connect/amazon-connect-streams/pull/360 as
mentioned by https://github.com/amazon-connect/amazon-connect-streams/issues/362 and https://github.com/amazon-connect/amazon-connect-streams/pull/384


Non-default file patterns aren't recognized by the cypressCodeLensePattern setting

Describe the bug
Code lenses aren't shown in files with non-default file extensions.
To Reproduce

Create a test file with a filename testfile.spec.tsx
Create another test file with a filename testfile.spec.ts
Add the following test to both files

  it('testing file patterns', () => {
    cy.get('html').then(() => {});
  });

By default, the test in the ts file should have lenses, the one in the tsx file should not
Change the cypressHelper.cypressCodeLensePattern setting to "**/cypress/**/*.{js,jsx,ts,tsx}"
The tests in both files should show lenses now, however, the one in the tsx does not

Expected behavior
The tests in both files should show lenses.
Environment (please complete the following information):

Extension version: 3.2.0
VS Code version: 1.73.0
OS: Windows | Mac | Linux (distro): Mac

** Developer Tools Console Output **

Hi @adamalston
Thanks for opening an issue!
Indeed, plugin activates just for javascript and typescript languages.
VS Code treats .tsx and .jsx files as separate languages (typescriptreact and javascriptreact).
Activation events for both are provided in extension v3.3.0.


JavaDocs

It was requested that we provide JavaDocs for CFLint.

closing for now.  initial javadocs to meet the sonatype requirements are there.


Alternatives to named(array)tuple?

Thanks for the great library! I've been trying to use it for an OpenGL env that doesn't like being fork()ed. That rules out using the default fork context in multiprocessing, which I've had to replace with spawn. Unfortunately there are several places (Gym env wrapper, Gym space wrapper, buffer_from_example, etc.) where rlpyt dynamically creates new namedtuple or namedarraytuple types and stores them as globals in some module. spawn does not preserve globals, so those types cannot be found in the child processes created by multiprocessing, and the whole thing falls down due to pickle errors. Although I haven't tried it, I expect something similar would happen if I tried to pickle buffers (e.g. to store demonstrations to disk) & then reload them in a different interpreter later on. This is a major limitation for my use case.
I've gotten around this problem by replacing namedtuple and namedarraytuple with duck-type equivalents that don't create a new type for each possible type name & combination of fields. Roughly it looks like the code below (for namedtuple; namedarraytuple is similar):
class NamedTupleSchema:
    # instances of this class act a bit like a type returned by namedtuple()
    def __init__(self, type_name, fields):
        self.type_name = type_name
        self._fields = fields
    def __call__(self, *values):
        # allows instances of `NamedTupleSchema` to act like `namedtuple` constructors
        return NamedTuple(self, values)

class NamedTuple(tuple):
    # instances of this class act like instances of namedtuple types
    def __new__(cls, schema, values):
        self = tuple.__new__(cls, values)
        self.schema = schema
        return self
    @property
    def __getattr__(self, name):
        # remaining methods (_make, _fields, etc.) are similar
        return self[self.schema._fields.index(name)]

This is hacky, but was the path of least resistance (e.g. all the buffer pre-allocation code still works fine without me changing anything outside collections.py). What would you think about incorporating a less hacky solution into rlpyt? I was thinking something along the lines of replacing all the namedtuple and namedarraytuple instances with nests of dicts/tuples/etc. The ergonomics of namedarraytuple could be preserved with a helper dict wrapper that supports array-based numeric indexing. Perhaps you have better ideas, though.

For posterity: to get spawn to work, it's also necessary to change the np_mp_array function to return something that actually has a reference to the MP shared array object. This was my solution. The current implementation just returns a plain numpy array, but that multiprocessing cannot pickle and unpickle that properly in general. With fork the old method works fine, but with spawn it will silently initialise a separate array with different contents for each child :cry:

Yikes!  That sort of silent bug is not fun to suffer.  Thanks for letting us know differences with spawn and fixes.  I’m finally getting back to making a sort of mock namedarraytuple class along your suggestion, will post it soon to see if it works in your case!
Out of curiosity, what is it about the forking that breaks OpenGL?  The environment instances are created inside the workers after they fork.  There is one exception though, an example environment is instantiated before forking, but it’s deleted.  I guess if you have to import opengl in some file header, that could cause the problem?

Out of curiosity, what is it about the forking that breaks OpenGL? … I guess if you have to import opengl in some file header, that could cause the problem?

Yes, my code was importing graphics libs in the parent process before forking (but not constructing environments). That could have been part of the issue. I don't know enough about the Linux graphics stack to explain why that would cause children to crash later on, though. For what it's worth, the crash only occurred when trying to blit to an FBO in the child; earlier OpenGL calls in the child went through fine.

Ran into a similar problem, and I found mp.Lock() objects are also not picklable, which is problematic when pickling any of the async buffers while sending them to a child process.

@qxcv Here is an attempt at building on your solution and with more safeguards in place to make sure the objects behave like namedtuples, for example making them immutable (it's on a new branch "namedtuple_schema"):
https://github.com/astooke/rlpyt/blob/namedtuple_schema/rlpyt/utils/namedtuple_schema.py
I think the pickling should work, too.  Would you mind giving it a quick try and see if it goes through?

Great, thanks for implementing this! I'm a bit busy today & tomorrow, but I should be able to try it out on Thursday afternoon & update this thread then.

@ankeshanand Interesting...what is the purpose of pickling the replay buffer?  Want to start a separate issue?

@qxcv I just pushed a few more changes to that branch, which makes all the buffer functionality compatible with either namedtuple or NamedTuple (luckily was very easy change!).  Also made a change to buffer_from_example() to accept a kwarg which flags whether to make a NamedArrayTuple or a namedarraytuple, regardless of which kind is inside the input example.  Hopefully it's a relatively easy fix from here to switch that flag and have the buffers all be the new kind.
I haven't touched the gym env wrappers tho.  I'll get back to that in a couple days if you haven't already done it by then.  :)

Works for me. I made a PR for the gym wrapper. Would you also like a PR for the np_mp_array fix?

Great thanks!  Took your gym wrapper PR.  And I only just saw the details of your much earlier NamedTupleSchema implementation...very nice!  Didn't mean to duplicate all that work hah.  So I incorporated a lot of that except for the _global_cache, although that was really nice.  Also I just moved everything into rlpyt.utils.collections to avoid some circular imports.
As for the np_mp_array fix, very slick.  Given that it's quite complicated compared to the original, what do you think about making it a separate function, next to the original, maybe named np_mp_array_spawn or something like that?  And at the top of the original function, write:
if mp.get_start_method() == "spawn":
    return np_mp_array_spawn(shape, dtype)
...rest of code

If you PR that, I'll merge it to this branch and then merge into master.  I renamed the gym files with _schema at the end, so when I merge into master I'll keep the originals.

Sounds good. Just filed #117 with those changes (I also bundled in some other small changes that I've been using to make my own code work).

All patched into master with merge commit: 99fb5b68d7ccbf0caa3c528734fe600340afd6b3  which includes #117.  I think that's all done here, to summarize:

shared memory should now support spawn (previously only fork) in np_mp_array (via np_mp_array_spawn).

pickling/unpickling of data buffers under spawn now supported using e.g. new NamedArrayTuple replacement for namedarraytuple; added new gym env and space wrappers (appended with _schema)

dynamic creation of namedarraytuple types also may be easier using the schema--no need to get into module globals

Let us know if we missed anything!
@ankeshanand if you want to work on the mp.Lock() issue some more, let's move that to a new issue?


load pretrained weights

Hi, why is k starting with 'norm' excluded when importing pre-trained weights? https://github.com/noahzn/Lite-Mono/blob/4874b35df8ed4da16159ce8be8c697028b72bf76/trainer.py#L661

Hi, because the pre-trained model was trained based on a classification task on ImageNet. For depth estimation we should not use some of the layers.

I'm not sure if I understand this correctly, but wouldn't this exclude the normalization layer as well?

By the way, is drop path rate the same for all models? I try to train lite-mono-tiny with drop path rate 0.2 but it didn't converge well.

I'm not sure if I understand this correctly, but wouldn't this exclude the normalization layer as well?

Hi, you can print out the network structures and see which layers are not loaded. I can't remember exactly.

By the way, is drop path rate the same for all models? I try to train lite-mono-tiny with drop path rate 0.2 but it didn't converge well.

As the training seed is not fixed, it is possible that the drop rate will result in poor training. If you have problems with overfitting, you can try a higher drop rate. For the tiny version, 0.2 should be sufficient. For the evaluation, please evaluate on the last 10-15 epochs, as you might get the best model at an earlier epoch.

@noahzn
Hello:
I just check the paper and code, is that meaning the pretrain only used for post-net?
Because I'm not found any gradient load for the depth-encoder and decoder.

@GLtangzero Hi, no, the ImageNet pre-trained weights are used in the depth-encoder, the pose-net uses resnet weights.

@noahzn
Hey, thanks for the super speed return!
I just find my mistake and delete the wrong commit.
Thanks again!

@noahzn Hey, thanks for the super speed return! I just find my mistake and delete the wrong commit. Thanks again!

I am now closing this issue as there is no further response.


@3.6.1 -<EMAIL_ADDRESS>

close #684

coverage: 99.245%. remained the same
when pulling abda34325955537c25f40b95fdbd717fc901cc00 on rc-3.6.1
into c6301440a2e8c657f327ec2a462b54187eca2d89 on master.


Automatic language detection for speech to text not working

Source language recognition is not working for the service region westeurope.
The application receives a SpeechStartDetected event followed by ResultReason::NoMatch.
Without language recognition the programs works as expected. The program uses StartContinuousRecognitionAsync().
Tested with C++ SDK 1.9 on Ubutu 18.04.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1ee95b20-a793-b370-f7a0-5661e9b2b569
Version Independent ID: 5a83c187-fad2-e1cb-e3cb-8af69b3edf83
Content: How to use automatic language detection for speech to text - Azure Cognitive Services
Content Source: articles/cognitive-services/Speech-Service/how-to-automatic-language-detection.md
Service: cognitive-services
Sub-service: speech-service
GitHub Login: @SusanHu
Microsoft Alias: qiohu

Resolved. Language recognition requires utterances with a few words. Otherwise no result is returned.

@hramoser  Hope you have self resolved and hence closed the issue. Thanks for the update.


Add Constraint Optimization Workload Allocation Stage

Add constraint optimization (CO) stage for the workload allocation
Add api call for CO
Update api call for genetic algorithm (GA)
Clean up main files keeping only two (one using GA and one using CO)
Introduce CostModelEvaluationLUT which replaces the structure of nested dictionaries to cache the hardware performance of different CNs on different cores
Various refactors of duplicate code

The restructuring work and file renaming is very nice! This makes it a lot more organized :)

I'm getting this error when running main_stream_co.py:
File "src/gurobipy/model.pxi", line 893, in gurobipy.Model.optimize
gurobipy.GurobiError: Model too large for size-limited license; visit https://gurobi.com/unrestricted for more information

Isn't this supposed to be detected by _sanity_check_gurobi_license ?


refactor: updated go version, removed duplicated code, more idiomatic approach

Updated Go version to v1.23
Moved constructor to separate router.go file
Removed the dependency between emit_openapi.go and fastapi.go
Added dependabot and Golang CI Linter
Added swagger example, which contains additionally hosting the UI itself
Moved validateHandler and AddCall to separate validate_handler.go file to remove the dependency and duplicate code + tests added
Updated all the packages to secure less vulnerable versions

Hey @sashabaranov !
I got inspired by the project. Could i ask you to check the PR update for the code?


run step 1 only - Permissions export

I'm looking to find a way to only run Step 1 to collect permissions and stop script after step 1 is completed.

To which script are you referring?

Hey @mahinder007 - I think you're probably referring to the Find-MailboxDelegates script. If so, you can comment out Lines 1028 thru 1032 from Script Version: 05012019. This will only run step 1 and not proceed with Steps 2 and 3.
Essentially these lines:
Write-LogEntry -LogName:$LogFile -LogEntryText "STEP 2 of 3: Analyze Delegates..." -ForegroundColor Yellow
Create-Batches -InputPermissionsFile $PermsOutputFile
Write-LogEntry -LogName:$LogFile -LogEntryText "STEP 3 of 3: Create schedule..." -ForegroundColor Yellow
Create-MigrationSchedule -InputBatchesFile $BatchesFile

@Mahinder007 - closing this one out. If you're still having issues let us know - happy to help.


Terminal Start Menu Pin doesn't have a title

When you pin the Windows Terminal app to the start menu, it doesn't have any title text, unlike most other apps.
Compare with VS, Sticky Notes, News, etc.

It is, in fact, a bug.


Syntax error fix (causes brew cask audit hard failure)

Please amend the commit message to include the name of the updated cask. Please @mention me after you do, so I get an email to check back.

Why do I need to mention the affected cask in the commit message?
There is no change specific to URL or data of the cask information itself...

Because without it it seems like you’re doing a general fix to the core, while it is not. A single cask is causing the issue, and we should know that at a glance.

Since I'm doing this from the web editor, I opened #1375 to have the correct commit message (instead of amending)

Merged this one by mistake (saw the reference and confused it for the fixed commit). No big deal. It would be better to have the cask specified, but it isn’t breaking.
Thank you.

Alright, thanks for clarifying btw :-)


Releases of Development / testing images should be automated

by having them manually pushed to dockerhub by developers, we risk getting bad images pushed. we should have a CI process to rebuild, update versions, and release

The images should also be tagged with the proper release versions, e.g. 20.3 for the 20.3.x branch and master or latest for the master branch. CI should use the corresponding tag (master should use master and stable branches should use the stable tag).
This would avoid the need to backport irrelevant changes when toolchain versions are bumped in master.

This was done in #2970.


Wrong echo response assumption

rust-ping wrongly assumes that the first package after a sent echo request always will be the response here: https://github.com/aisk/rust-ping/blob/e4b4432a1e488da6f94d05437d6aa0efe197d13b/src/ping.rs#L65
It may be the case that there are other ICMP packages in the same socket. [1]
A simple case where the next package received is not the reply is when you ping yourself. In that case the first package received is the just-sent echo request and not the reply. Therefore this crate will give a false negative on the ping-ability of a host.
Instead of assuming the response of a echo request is next package that arrives on the socket, this crate should listen on the socket and ignore any packages that do not match (instead of reporting an internal error) until the timeout ends. Of course Ok should be returned if a correct response is seen.
Please refer to the implementation of the the "normal" ping where the package is explicitly ignored in the ping4_parse_reply function: https://github.com/iputils/iputils/blob/1c081524ee463842631c708d060119ebc7ca699f/ping/ping.c#L1668 (I chose IPv4 as an example)
I do not have a suggested implementation yet. I have only just identified the issue right now.
[1] Not my words, see the "normal" ping implementation comments here: https://github.com/iputils/iputils/blob/1c081524ee463842631c708d060119ebc7ca699f/ping/ping.c#L1580

There was a pending PR on it, see #7.

There was a pending PR on it, see #7.

I did take a look at #7, but as far as I can tell it does not fix the underlying issue that I am seeing here. While there is a loop to retry, the check that currently makes the function return an internal error is still unchanged/unguarded. It should "continue" to something similar to restart the loop instead of returning internal error.
Also, I am not sure why #7 got stuck as a pending PR?

Sorry, I understand what you mean now. Yes, this is not the issue that #7 wants to resolve. It only ignoreds the mismatch ident reply message, but as you point out, the decode error should also be ignored.
#7 has some pending review suggestions which have not been updated. I'll continue the work if no one wants to investigate it a few days later.

I'm relatively new to Rust, to make a PR for this issue would properly be fun. I hope I'll have time for it soon :) - I have got an idea for how to fix it.

Please don't have any burden, any issues and PRs will be appreciate!

closed by #20


Support ECDSA certificates on server side and show parameters in dialog

This PR lifts restrictions on certificate bits for server-side certificates, so that administrators can freely choose the type of certificates. This enables the use of ECDSA certificates.
Since ECDSA certificates (e.g. from Let's Encrypt) are super easy to get and increasingly preferred by many, I believe the change is important.
Ideally, we should make an aligned change in certificate handling for both client and server side. But since client side (e.g. certificate-based authentication) is more involved as we need to handle sign / verify functions, I am currently not changing that. Comments are welcome.
The certificate dialog in Windows UI won't display the ECC bits for the time being. This can also be improved later.
Fix #1034

Tested with CI artifacts.
Windows UI now shows the type along with the bits, such as "ECC 256 bits" or "RSA 2048 bits".
@davidebeatrici Could you please take a look at my handling of unicode string in WinUI.c? I am really unsure how it can be done gracefully.

despite we bound to openssl-1.1.1 and higher, it might be built without ECDSA support, see https://github.com/openssl/openssl/commit/3b6aa36c77307dbb22b767b484a62e8e5e4bcc4e
I suggest to add corresponding check in CMake (for example, https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/Mayaqua/CMakeLists.txt#L26 ) that openssl is built using ECDSA

I am not sure if it's needed as we are not going to change the default key from RSA. The user is responsible to make sure the OpenSSL and the default cipher supports ECDSA. For example if the default cipher is AES128-SHA it won't work.

Users sometimes pick openssl from distribution. It would be good to check during cmake that openssl supports ecdsa.
However, I agree it is not critical. We'll fail during build anyway

Another way is adding the check in the check command.

please ignore my suggestion. seems, "OPENSSL_NO_ECDSA" is gone from OpenSSL now.
should we merge and give it a go ?

I think it's ready to merge. Just the string process in WinUi.c feels a bit clumsy.

Ideally the certificate type should be on a separate line. I haven't figured out how to do that.

I revamped the certificate dialog. Now it shows key type and parameters.

let us merge and see.
I tried to build myself using our "build for windows" guide. it is indeed broken, pity that nobody except @domosekai  complains :(
also, I investigated binaries using https://github.com/DynamoRIO/drmemory , there are few findings, but they to be there for long time. no need to block merging


feat: Map Chart widget

Description

The first MVP of the Map Chart widget
Fixes #6314

Type of change

New feature (non-breaking change which adds functionality)
This change requires a documentation update

How Has This Been Tested?

Test A
Test B

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:green_circle: Total coverage has increased
// Code coverage diff between base branch:release and head branch: feature/6314-map-chart-widget

Status
File
% Stmts
% Branch
% Funcs
% Lines

:green_circle:
total
55.07 (0.03)
36.57 (0.01)
34.5 (0.01)
55.59 (0.03)

:red_circle:
app/client/src/icons/WidgetIcons.tsx
61.45 (-0.28)
100 (0)
17.95 (-0.47)
61.45 (-0.28)

:green_circle:
app/client/src/utils/autocomplete/TernServer.ts
52.94 (0.23)
41.67 (0.84)
36.21 (0)
56.99 (0.25)

:sparkles: :new:
app/client/src/widgets/MapChartWidget/constants.ts
100
100
100
100

:sparkles: :new:
app/client/src/widgets/MapChartWidget/index.ts
100
100
100
100

:sparkles: :new:
app/client/src/widgets/MapChartWidget/widget/index.tsx
58.97
0
40
59.46

The current build is failing due to some console statements.

Build failing due to this error.
An easy way to track this is by checking the console on your local before pushing.

DP build still failing :/.

@wmdev0808 can you run yarn install and push again

@somangshu something weird with this PR. the build does not get build.
@ashit-rath I remember this happened with you too. what did you do to resolve this?

@jsartisan IIRC I was importing an enum from ChartComponent and that kind of made the whole component load in the main chunk.
I think that this might cause this issue. Can you comment that import, try building it locally and see i that reduces the bundle size?

@ashit-rath that's exactly what is happening right now. The chunk size has increased to 9.12 MB and that more than the limit, this is happening because there are multiple map files included for the map chart data. Ideally chunk optimisation takes care of this.
We are still not sure what the solution is here. @wmdev0808 please add anything I might have missed

@jsartisan @ashit-rath @wmdev0808 the build pass on increasing the cache size in the build config. My question now is that if the chunk size is acceptable?
@wmdev0808 we also need to check if we are doing the imports correctly and not loading any files which might not be required.
cc @riodeuno @SatishGandham

@jsartisan @ashit-rath @wmdev0808 the build pass on increasing the cache size in the build config. My question now is that if the chunk size is acceptable?
@wmdev0808 we also need to check if we are doing the imports correctly and not loading any files which might not be required.
cc @riodeuno @SatishGandham

@somangshu I've reviewed the existing code base and I couldn't find any code mess.
In addition, I've analyzed the chunk and here are results:

FusionCharts: 2.49MB
FusionMaps: 1.52MB
Currently, we are statically importing 8 map definition files(every definition file has size of 50KB ~ 461.91KB).
To sum up,
We can consider the dynamic import way of these definition files when they are required, I am not sure with the solution yet.
Increased chunk size due to introducing FusionCharts, FusionMaps is inevitable, I guess.

@somangshu @wmdev0808 My suggestion here would be to move out the typings and the constants (dataSetForWorld/dataSetForWorldWithAntarctica) from the MapChartComponent to its separate files.
It would do 2 things

Moving the constants to a separate file would make the component leaner.
As the typings are referred to in another component, webpack is picking up the whole and putting it in the main bundle thus increase the size. Thus having the typings in a separate file would make webpack not touch the main component (MapChartComponent).

@wmdev0808 We will need cypress tests for the regular workflows here.

onEntityClick workflow
switch map type workflow
Add title workflow
Hide/show labels workflow
Custom map config workflow.

These are quite similar to the chart widget tests. You could take inspiration from there.

@jsartisan @riodeuno need to know what is pending here, This is stuck for quiet a while now

@wmdev0808 related tests have failed here

@wmdev0808 related tests have failed here

@somangshu , I've reviewed the test cases, it is failing on calling createModal cypress command.
It happens in all the cypress test cases using the above command, so it's not the issue specific to this PR

/ok-to-test sha=bc17ffd

https://github.com/appsmithorg/appsmith/actions/runs/1421167047

The same test only present in this branch is failing, Please check Smoke_TestSuite/ClientSideTests/DisplayWidgets/MapChart_spec.js line no :106, I dont really understand what are we trying to achieve here. Do try to remove this, And run locally, we should see the error go away

@wmdev0808 The same test only present in this branch is failing, Please check Smoke_TestSuite/ClientSideTests/DisplayWidgets/MapChart_spec.js line no :106, I dont really understand what are we trying to achieve here. Do try to remove this, And run locally, we should see the error go away

@somangshu ,
That test case is for ensuring onEntityClick action, that is, when the user click on the map's entity, it should popup a modal.
It was working before.
At the moment, I will just comment it out

/ok-to-test sha=67c4714

https://github.com/appsmithorg/appsmith/actions/runs/1424887995

Understood, that makes sense. @wmdev0808 can we replace the action executed onEntityClick
@rahulramesha this might be related to the modal widget. Do you mind taking a look at the problem here.

Understood, that makes sense. @wmdev0808 can we replace the action executed onEntityClick
@rahulramesha this might be related to the modal widget. Do you mind taking a look at the problem here.

@somangshu , I can see it is not working in other places using common cypress command createModal , so it would be better if someone who wrote that command look into the issue

https://github.com/appsmithorg/appsmith/actions/runs/1434063353

/ok-to-test sha=409a8fd

@momcilo-appsmith @vasanth-appsmith can u guys have a look of the widget icon in the deploy preview.

@marks0351 Please use this icon: https://www.figma.com/file/ATfTB5F9Q7ZiI0yYckuXW7/Deprecated-Design-System?node-id=72%3A8484

/ok-to-test sha=e504459

When I change the colour, it is not updated in the widget unless i move the widget or refresh the page. selectedDatapoint value is still not available. I can see the autocomplete but there is no value output. Pls add test cases around using selectedDatapoint to show a message or toggle another widget.

Hi @marks0351 ,
Unfortunately, The above comments does not make sense for me.
I'd like to confirm it

/ok-to-test sha=cb2a5c9

@wmdev0808 Started testing this feature and please find the issues below,
Issue 1 - Choosing any of the map type (ex - Asia ) and changing the position of the widgets - Reloads the map to the 'world map' but still the map type is Asia in the property pane
https://www.loom.com/share/1d45780eba774cf297d52d57c2a2e5bc
Issue 2 - Map chart icon is not displayed in the entity explorer
https://www.loom.com/share/af32d8793a8d4ad99d28016bc546e5ac
Issue 3 - Colour range and data field accepts duplicate value and no validation message is displayed

Issue 4 - Choosing any of the map (Ex- Europe) and clicking on deploy initially loads the world map in the deploy mode and double clicking on any of the region on the map reloads the widget to Europe
https://www.loom.com/share/478ac8e5125549f699655f5660afb825

@somangshu The figma link attached to this feature does not have design related to Map chart. Can you help me with the valid figma design

The design attached it only for the icon @YogeshJayaseelan,
Please test this widget out similar to the chart widget. Testing out various configuration is more important

Issue 10 - Question - For each map type the colour code can be different right? currently the colour code added for one map type is applicable for other map types too

No, color range array are widget-scoped, not map type based one

/ok-to-test sha=894544a

/ok-to-test sha=c6ad1f2

/ok-to-test sha=58166c4

@wmdev0808 related test is failing here

/ok-to-test sha=74f7339

/ok-to-test sha=74f7339

/ok-to-test sha=59d9f99

@wmdev0808 Re-Tested this PR and please find the status below,
Issue 1 - Fixed
Issue 2 - Fixed,
Issue 3 - Reopen - with following steps - Add two or three duplicate values - And changing one of the duplicated values to any existing value and observe - Refer video below
https://loom.com/share/50b6e8e340eb41c08fa61c65a60095af
Issue 4 - Fixed
Issue 5 - Fixed
Issue 6 - Reopen - With following steps - Disable the colour code and reposition the widget and observe
https://www.loom.com/share/c43ad44af72d467c8463b327fb7d8ce5
Issue 7 - Fixed
Issue 8 - Fixed
Issue 9 - Fixed
Issue 10 - Accepted as Default Behaviour
New issues
Issue 11 - In the colour code option if the Min and max value are reversed for any the new value with an existing value then duplicate color code is displayed don the widget
https://www.loom.com/share/92a7f7120e9a43758ebb144e468af3cf
Issue 12 - Colour code option - Min and Max value cannot be same - No validation error is displayed
https://loom.com/share/b377a85ace7247eca5b07fbb55fcd1c5

@YogeshJayaseelan here is my observation:

ISSUE 3 - This is a non issue as the object you are considering is not unique and hence showing up properly on the widget component, Otherwise this is of low priority and does not need solving right now
ISSUE 6 - invalid issue, mix of user input and dev experience
ISSUE 11 - low priority, can be a separate issue
ISSUE 12 - According to me in a range the low and high can both be the same, This is a valid case and not a bug, the component is also handling it well

Kindly give a sign off if the above is acceptable
cc @wmdev0808

@wmdev0808 Tested this PR and please find the status below,
Issue 1 - Fixed
Issue 2 - Fixed,
Issue 3 - Not in scope
Issue 4 - Fixed
Issue 5 - Fixed
Issue 6 - Not an issue
Issue 7 - Fixed
Issue 8 - Fixed
Issue 9 - Fixed
Issue 10 - Accepted as Default Behaviour
Issue 11 - Will raise an separate issue
Issue 12 - Not an issue
New issues:
Issue 13 - TypeError: Cannot read properties of undefined (reading 'paper')  occurs in console when the widget is repositioned
https://loom.com/share/ae27b6ba16da44b3b494d4f45cf8309c
Issue 14 - Resizing of widget. Widget border moves without the content inside
https://loom.com/share/d6b60d8bd6ad4e2ea15d36ddfccf0c50

/ok-to-test sha=f55a5d0

@wmdev0808 Tested this PR.
Issue 14 still exists partially when widget is moved to the left
https://loom.com/share/b17d7b18ae104d3fbe7ad63b04bd057e
New issues observed

When display value is long the Color range looks bigger than the chart itself. Ideally it should be the other way round

With map type Ocenia, there is slight overlapping on values with display values and without display values.

Expected structure and example for Map chart data shows string but accepts numbers.

Scroll is not smooth, when clicked on the scroll bar the widget moves, user has to use the arrow keys to move in edit mode.
https://loom.com/share/23f6ad91915045f09e5bb480e0fd8e35

@shwetha-ramesh ,
I've walked through the whole issues with @somangshu.

14, 17, 18: They are not issues, so you can just ignore
15, 16: You can create new issues

/ok-to-test sha=263c7a9

@shwetha-ramesh , I've walked through the whole issues with @somangshu.

14, 17, 18: They are not issues, so you can just ignore
15, 16: You can create new issues

Will be creating separate issues for 15 & 16. Rest looks good.
cc: @YogeshJayaseelan