jackett: 0.21.1672 -> 0.21.1861

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1693
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1693 with grep in /nix/store/q5djw2xwymbsgyrnlzck7ag5dwk2jrgp-jackett-0.21.1693
found 0.21.1693 in filename of file in /nix/store/q5djw2xwymbsgyrnlzck7ag5dwk2jrgp-jackett-0.21.1693

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/0db97729ee49e784e33d41850c9d037b6b43ff35#jackett

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

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1721
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1721 with grep in /nix/store/l780r8bsj6ib0mi6bx5mba3n1ccqrghi-jackett-0.21.1721
found 0.21.1721 in filename of file in /nix/store/l780r8bsj6ib0mi6bx5mba3n1ccqrghi-jackett-0.21.1721

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/6d75ba0f88a5b1859864bf86703b9c256d665806#jackett

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

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1750
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1750 with grep in /nix/store/5aln26whgkfp7hc66kwz95csg8hvs216-jackett-0.21.1750
found 0.21.1750 in filename of file in /nix/store/5aln26whgkfp7hc66kwz95csg8hvs216-jackett-0.21.1750

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/9623b3fed0027180fc4693ff6fc9376fe39cd666#jackett

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/5aln26whgkfp7hc66kwz95csg8hvs216-jackett-0.21.1750
ls -la /nix/store/5aln26whgkfp7hc66kwz95csg8hvs216-jackett-0.21.1750/bin

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1776
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1776 with grep in /nix/store/bb1hh7y26mcazxmc7bdn1yykicyd4hf8-jackett-0.21.1776
found 0.21.1776 in filename of file in /nix/store/bb1hh7y26mcazxmc7bdn1yykicyd4hf8-jackett-0.21.1776

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/c5d06bcb893c912c5032e7f3bb5d1c9e53342d03#jackett

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

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1797
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1797 with grep in /nix/store/33ky37jcag23q7dxsfqqqff461vr5rcf-jackett-0.21.1797
found 0.21.1797 in filename of file in /nix/store/33ky37jcag23q7dxsfqqqff461vr5rcf-jackett-0.21.1797

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/8aea4d829a7440cd6fe73305b63fc390edc244b7#jackett

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/33ky37jcag23q7dxsfqqqff461vr5rcf-jackett-0.21.1797
ls -la /nix/store/33ky37jcag23q7dxsfqqqff461vr5rcf-jackett-0.21.1797/bin

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1832
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1832 with grep in /nix/store/422wj9a9qy44xigfpisri6fm9lpsnxkn-jackett-0.21.1832
found 0.21.1832 in filename of file in /nix/store/422wj9a9qy44xigfpisri6fm9lpsnxkn-jackett-0.21.1832

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/1398683050e9dc451146eb2137656ef6e4e22625#jackett

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/422wj9a9qy44xigfpisri6fm9lpsnxkn-jackett-0.21.1832
ls -la /nix/store/422wj9a9qy44xigfpisri6fm9lpsnxkn-jackett-0.21.1832/bin

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1861
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1861 with grep in /nix/store/f0cngyyl9isd77ab3a6mrn57pg5k78af-jackett-0.21.1861
found 0.21.1861 in filename of file in /nix/store/f0cngyyl9isd77ab3a6mrn57pg5k78af-jackett-0.21.1861

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/ca219c6d9cbf5e1c94349fd3b40deafc38d427a3#jackett

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

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jackett is: API Support for your favorite torrent trackers
meta.homepage for jackett is: https://github.com/Jackett/Jackett/
meta.changelog for jackett is: https://github.com/Jackett/Jackett/releases/tag/v0.21.1915
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.21.1915 with grep in /nix/store/05mai9p2v5psripfdk8pgg44q6vgf9mm-jackett-0.21.1915
found 0.21.1915 in filename of file in /nix/store/05mai9p2v5psripfdk8pgg44q6vgf9mm-jackett-0.21.1915

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jackett

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/8f8623c31c3c30e8cb4f15412cd2adec7488cb17#jackett

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/05mai9p2v5psripfdk8pgg44q6vgf9mm-jackett-0.21.1915
ls -la /nix/store/05mai9p2v5psripfdk8pgg44q6vgf9mm-jackett-0.21.1915/bin

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

1 package built:

jackett

Maintainer pings
cc @edwtjo @nyanloutre @purcell for testing.

Result of nixpkgs-review pr 286764 run on aarch64-darwin 1

1 package built:

jackett


Enable CD on Environment Script

Link to GitHub repository

https://github.com/jenkinsci/environment-script-plugin
When modifying release permission
List the GitHub usernames of the users who should have commit permissions below:

@dawidmalina

This is needed in order to cut releases of the plugin or component.
If you are modifying the release permission of your plugin or component, fill out the following checklist:

### Release permission checklist (for submitters)
- [x] The usernames of the users added to the "developers" section in the .yml file are the same the users use to log in to [accounts.jenkins.io](https://accounts.jenkins.io/).
- [x] All users added have logged in to [Artifactory](https://repo.jenkins-ci.org/) and [Jira](https://issues.jenkins.io/) once.
- [x] I have mentioned an [existing team member](https://github.com/orgs/jenkinsci/teams) of the plugin or component team to approve this request.

When enabling automated releases (cd: true)
Follow the documentation to ensure, your pull request is set up properly. Don't merge it yet.
In case of changes requested by the hosting team, an open PR facilitates future reviews, without derailing work across multiple PRs.
Link to the PR enabling CD in your plugin

https://github.com/jenkinsci/environment-script-plugin/pull/28
### CD checklist (for submitters)
- [x] I have provided a link to the pull request in my plugin, which enables CD according to the documentation.

### Reviewer checklist
- [ ] Check that the `$pluginId Developers` team has `Admin` permissions while granting the access.
- [ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
- [ ] If security contacts are changed (this includes add/remove), ping the security officer (currently `@Wadeck`) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it.

Bear in mind, CD will not work if your repository has no Jenkinsfile: https://github.com/jenkinsci/archetypes/blob/master/common-files/Jenkinsfile


Store locator missing on PWA

Is your feature request related to a problem? If yes, please describe it.
On the PWA version I didn't find how to reach the store locator search engine.
Describe the desired solution.
Having the search engine for store locator like on classic version of Intershop
Describe alternatives you've considered.
no alternatives identified
Provide additional context.

I close this issue because in fact there's an issue declared here : https://github.com/intershop/intershop-pwa/issues/729

Reopening the issue since the store locator is still missing


Fix Python package requirements filtering

Fixes https://github.com/chanzuckerberg/napari-hub/issues/482.
The errornous entry is specified as

'pytest-xvfb ; (sys_platform == "linux") and extra == \'testing\''

Removing the semicolon in the filter will correclty remove this entry from https://www.napari-hub.org/plugins/napari-matplotlib.

Verified it's working as expected, awesome job 👍
Before

After


wsdl document url generate from host rather than localhost

wsdl docment url address location change according to request host and port
Current wsdl docment address location is fixed at http://localhost:8000 no matter where you send http request to <IP_ADDRESS>, or send from third hosts.
This behavior will cause generating wrong soap post url using soap tools like soapui.
<wsdl:service name="Calculator">
<wsdl:port name="CalculatorSumOperation" binding="CalculatorSumOperation">
<soap:address location="http://localhost:8000/Calculator/SumOperation"/>
</wsdl:port>
</wsdl:service>

This commit will change wsdl address location url according to request host.
When you request to http://host:port, the wsdl document address location url will be convert to http://host:port rather than http://localhost:8000.
When soap service deploy on other host, ip,port say <IP_ADDRESS>:5000, the wsdl docment address localhost url will be:
<wsdl:service name="Calculator">
<wsdl:port name="CalculatorSumOperation" binding="CalculatorSumOperation">
<soap:address location="http://<IP_ADDRESS>:5000/Calculator/SumOperation"/>
</wsdl:port>
</wsdl:service>

address location get from request.url to get whole url with prefix.
many soap tools usally get wsdl document with ?wsdl parameter:
GET http://<IP_ADDRESS>/soap/services/?wsdl
which will cause generate wrong wsdl location url:
http://<IP_ADDRESS>/soap/services/?wsdl/{method}
so i did a littile judgement:
if request url ends with `?wsdl`:
        http://<IP_ADDRESS>/soap/services/?wsdl -> http://<IP_ADDRESS>/soap/services/{method}
  if not then just add method:
      http://<IP_ADDRESS>/soap/services/ -> http://<IP_ADDRESS>/soap/services/{method}

I have tested with nginx as proxy:
location /soap {
            proxy_pass http://<IP_ADDRESS>:5002;# proxy send to http, so it generate with `http`
            proxy_http_version  1.1;
            proxy_cache_bypass  $http_upgrade;

            proxy_set_header Upgrade           $http_upgrade;
            proxy_set_header Connection        "upgrade";
            proxy_set_header Host              $host;
            proxy_set_header X-Real-IP         $remote_addr;
            proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host  $host;
            proxy_set_header X-Forwarded-Port  $server_port;
        }

the wsdl address location url:
http://{domain}/soap/SumOperation1
so the http protocol depends on proxy_pass protocol, still need to change http to https to send POST soap

address location get from request.url to get whole url with prefix.
many soap tools usually get wsdl document with ?wsdl parameter:
GET http://<IP_ADDRESS>/soap/services/?wsdl
which will cause generate wrong wsdl location url:
http://<IP_ADDRESS>/soap/services/?wsdl/{method}
so i did a littile judgement:
if request url ends with `?wsdl`:
        http://<IP_ADDRESS>/soap/services/?wsdl -> http://<IP_ADDRESS>/soap/services/{method}
  if not then just add method:
      http://<IP_ADDRESS>/soap/services/ -> http://<IP_ADDRESS>/soap/services/{method}

I have tested with nginx as proxy:
location /soap {
            proxy_pass http://<IP_ADDRESS>:5002;# proxy send to http, so it generate with `http`
            proxy_http_version  1.1;
            proxy_cache_bypass  $http_upgrade;

            proxy_set_header Upgrade           $http_upgrade;
            proxy_set_header Connection        "upgrade";
            proxy_set_header Host              $host;
            proxy_set_header X-Real-IP         $remote_addr;
            proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host  $host;
            proxy_set_header X-Forwarded-Port  $server_port;
        }

the wsdl address location url:
http://{domain}/soap/SumOperation1
the protocol depends on proxy_pass protocol, still need to change http to https to send https POST.

Good point @gcdsss
In fact it is possible prevent that a wrong URL to be made not only for ?wsdl query string, but for any query string or fragment.
Instead a method to handle with conditional flow, it can be achieved by simply use built-in methods:
location = f'{str(request.url.replace(query="", fragment="")).rstrip("/")}/{method}

great！tested and work.


fix: The Kubernetes extension now supports modified pods by checking to see if a deletion timestamp has been set and cleans up the in-memory state if so

Description
The kubernetes extension only directly supports addition and deletion of pods.  The deletion for a pod does not arrive until the pod has been hard-deleted, creating a span of time during which the cluster can still think the pod is alive.  For instance, if an indexer pod is deleted, the process in the pod shuts down immediately, but the kubernetes deletion event doesn't occur until a later time.  During this time, the coordinator has a memory reference to the defunct pod and will continue attempting to communicate with it until the deletion officially occurs.

K8sNodeDiscoveryProvider now directly supports modified pods.  When a pod modification event is processed the pod metadata is checked to see if there is a creation timestamp and a deletion timestamp.  If both exist, and the deletion timestamp is after the creation timestamp, the pod can be considered immediately deleted.  In this situation the node information is removed from the coordinator memory and it stops attempting to communicate with the defunct pod.
This change entails added the two timestamps to DruidDiscoveryNodeAndResourceVersion which has been renamed too DiscoveryDruidNodeAndK8sMetadata as it now contains more information than just the pair indicated.

Fixed the bug ...
Renamed the class ...
Added a forbidden-apis entry ...

Key changed/added classes in this PR

MyFoo
OurBar
TheirBaz

This PR has:

[ ] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[ ] added documentation for new or modified features or behaviors.
[ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[ ] added integration tests.
[ ] been tested in a test Druid cluster.

Any way to add a unit test for the new case?


Session id is generated in response to ANNOUNCE instead of SETUP requests

Which version are you using?
v0.17.16
Which operating system are you using?

[x] Linux arm7 standard
[x] Windows amd64 standard

Describe the issue
Session identifier is generated in response to ANNOUNCE requests (and is expected in SETUP requests?).
Regarding RFC2326 and RFC7826, it should be generated in response to the SETUP requests:
https://datatracker.ietf.org/doc/html/rfc2326#page-33:

The server generates session identifiers in response to SETUP requests.

https://datatracker.ietf.org/doc/html/rfc7826#section-2.2:

When receiving a SETUP request, the server determines if the media resource is available and if one or more of the of the transport parameter specifications are acceptable.  If that is successful, an RTSP session context is created and the relevant parameters and state is stored.  An identifier is created for the RTSP session and included in the response in the Session header

https://datatracker.ietf.org/doc/html/rfc7826#section-18.49:

An RTSP session is created by the server as a result of a successful SETUP request, and in the response, the session identifier is given to the client.

I had a problem (#822) with an IP camera that sends the session id not at the SETUP request, but at the following requests. We found a workaround for the moment, but if it is not too complicated to change one day, that would be nice.
Thanks again for sharing your hard work with us
Tom

Hello, thanks for sharing this info, sometimes protocol misinterpretations are found and corrected whenever possible.
The problem here is that sessions are used to uniquely identify RTSP publishers and readers, since these can disconnect and reconnect to the server, and connections are not enough for the purpose. Furthermore, client status (is publishing / is reading, what is reading, etc) is associated to the session, not in the client, for the same reason. I still believe that sessions are the best place to save client data, independently from the fact that a client has issued a SETUP request.
In my opinion the best way to solve this issue is hiding the session header from ANNOUNCE responses, without touching anything else.

I'm not sure if I understood the problem of #822 correct, but I think as the camera doesn't send the session id at the setup request, the server started again the function newServerSession and with the new session id the former info of the announcement got lost. Does that sound plausible? If that's the case, then hiding isn't enough.
I'm fine with our workaround, I just want to mention it in case someone else runs into the same problem.

as the camera doesn't send the session id at the setup request, the server started again the function newServerSession and with the new session id the former info of the announcement got lost

There are two possible approaches:

scraping the hidden session idea, saving ANNOUNCE data into the connection and creating a session only during SETUP
adding a "session" field to the connection, using it to save the current session (that is created during ANNOUNCE) and read it during SETUP requests. A client is not intended to interact with multiple sessions, so this is fine.

I'm sharing my thoughts before doing anything since this is a sensitive issue, and any change must not cause problems elsewhere.

Both ideas sound good to me

It's stick with the second approach, that consists in creating a session during ANNOUNCE (but not sending its id through the response), since in this way the server is allowed to check if a stream can be created or not during ANNOUNCE.
Furthermore, a connection doesn't have a "state" field, therefore a connection would be free to send multiple ANNOUNCE requests without any check. A session, contrarily,  has a "state" field that allows to check if a client is trying to send multiple ANNOUNCE requests or invalid requests.

Thank you for the very fast fix, I can confirm that the latest commit fixed my problem :-)
After SETUP, the camera puts a PLAY request which gets answerd by a Bad Request "...(must be in state [prePlay play], while is in state preRecord)" But as this is another problem I first try to find out if it is a server or camera bug. I can use it by changing the cases Play and Record. I'll open another issue when I have more info.
Thanks again, your server fits perfect for my project. I didn't find something comparable (except Wowza Streaming Engine for 175 Euro montly, which is not an option).

Sorry, it only works if thers no basic auth.
With activated auth I get:
2022/02/19 21:31:21 INF [RTSP] listener opened on :8554 (TCP)
2022/02/19 21:31:21 INF [HLS] listener opened on :8888
2022/02/19 21:31:21 INF [API] listener opened on stream.fritz.box:9997
2022/02/19 21:31:37 INF [RTSP] [conn <IP_ADDRESS>:4953] opened
2022/02/19 21:31:37 DEB [RTSP] [conn <IP_ADDRESS>:4953] [c->s] ANNOUNCE rtsp://stream.fritz.box:8554/live/123456 RTSP/1.0
CSeq: 1
Content-Length: 399
Content-Type: application/sdp

v=0
o=- 86902271 86902271 IN IP4 <IP_ADDRESS>
s=
i=
c=IN IP4 <IP_ADDRESS>
t=0 0
a=x-qt-text-nam:
a=x-qt-text-inf:
a=x-qt-text-cmt:source application:Whee
a=x-qt-text-aut:
a=x-qt-text-cpy:
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42801E;sprop-parameter-sets=J0KAHtoCgPTAVSAAAAMAIAAAB4wIACSeAAkn173wvCIRqA==,KM48gA==
a=control:trackID=1

2022/02/19 21:31:37 INF [RTSP] [session 867990231] opened by <IP_ADDRESS>:4953
2022/02/19 21:31:37 DEB [RTSP] [session 867990231] non-critical authentication error:
2022/02/19 21:31:37 DEB [RTSP] [conn <IP_ADDRESS>:4953] [s->c] RTSP/1.0 401 Unauthorized
CSeq: 1
Server: gortsplib
WWW-Authenticate: Basic realm="IPCAM"

2022/02/19 21:31:37 DEB [RTSP] [conn <IP_ADDRESS>:4953] [c->s] ANNOUNCE rtsp://stream.fritz.box:8554/live/123456 RTSP/1.0
Authorization: Basic c3RyZWFtZXI6ZHJlYW1lcg==
CSeq: 2
Content-Length: 399
Content-Type: application/sdp

v=0
o=- 86902271 86902271 IN IP4 <IP_ADDRESS>
s=
i=
c=IN IP4 <IP_ADDRESS>
t=0 0
a=x-qt-text-nam:
a=x-qt-text-inf:
a=x-qt-text-cmt:source application:Whee
a=x-qt-text-aut:
a=x-qt-text-cpy:
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42801E;sprop-parameter-sets=J0KAHtoCgPTAVSAAAAMAIAAAB4wIACSeAAkn173wvCIRqA==,KM48gA==
a=control:trackID=1

2022/02/19 21:31:37 DEB [RTSP] [conn <IP_ADDRESS>:4953] [s->c] RTSP/1.0 400 Bad Request
CSeq: 2
Server: gortsplib

2022/02/19 21:31:37 INF [RTSP] [conn <IP_ADDRESS>:4953] closed (connection is linked to another session)
2022/02/19 21:31:37 INF [RTSP] [session 867990231] closed (not in use)

I think the session must be closed right away after

2022/02/19 21:31:37 DEB [RTSP] [conn <IP_ADDRESS>:4953] [s->c] RTSP/1.0 401 Unauthorized

or at least before the next ANNOUNCE

Thanks, I'd say it is fixed

added in v0.18.0


Leaderboard levels/messages

Every time, I run the command I get the error, TypeError: db.startsWith is not a function.
Could someone help me fix this?


variant: how to inherit some of the parent fields

I am looking to setup a model for wine, and I'm wondering how to efficiently set up the variants.
There is a new variant every year having the same

name
wine type (red, rosé, white, ..)
but different
grape varieties (cépage in French)
price
vintage

This is not an urgent oscar issue but I hope it's still is a valid question because of the parent inheritance.
Technical details

Python version: 3.10.12
Django version: 4.2.6
Oscar version: 3.2.2

Hi Christian,
The children inherit the attribute values from the parent.
If you fill these out in parent products and leave them empty in the child products they should appear on the detail page / in the filters.

On 23 Oct 2023, at 14:21, Christian @.***> wrote:
I am looking to setup a model for wine, and I'm wondering how to efficiently set up the variants.
There is a new variant every year having the same
name
wine type (red, rosé, white, ..)
but different
grape varieties (cépage in French)
price
vintage
This is not an urgent oscar issue but I hope it's still is a valid question because of the parent inheritance.
Technical details
Python version: 3.10.12
Django version: 4.2.6
Oscar version: 3.2.2
—
Reply to this email directly, view it on GitHub https://github.com/django-oscar/django-oscar/issues/4190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMIFRKEZNQQSHQXXX6LGYZDYAZOMJAVCNFSM6AAAAAA6L7JCPSVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2TOMBTGU3DSNQ.
You are receiving this because you are subscribed to this thread.

Ok, perfect, thanks @viggo-devries
I take it for the grape variety, since it's not a trivial attribute, I have to add a custom one?
E.g. it's several types of percentages adding up to 100%.

You can add the “grape variety” attribute and fill it out on every child, if it’s filled it on the child it doesn’t look at it’s parents attribute value.
This way you can “override” the parents attributes

On 23 Oct 2023, at 14:56, Christian @.***> wrote:
Ok, perfect, thanks @viggo-devries https://github.com/viggo-devries
I take it for the grape variety, since it's not a trivial attribute, I have to add a custom one?
E.g. it's several types of percentages adding up to 100%.
—
Reply to this email directly, view it on GitHub https://github.com/django-oscar/django-oscar/issues/4190#issuecomment-1775134347, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMIFRKHXRRWJXIKQRUAUIMLYAZSQ5AVCNFSM6AAAAAA6L7JCPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZVGEZTIMZUG4.
You are receiving this because you were mentioned.

Hi the issue reporter is for issues, if you need help please ask elsewhere.

A little harsh but I get it :-)
I did ask in the Google group but got no replies.


Poor extendability

How can I easily subclass ClassLoaderLeakPreventorListener into MyClassLoaderLeakPreventorListener? My goals is to disable some cleanups.
Essentially, I think all that would be needed is for line 205 to become
    // Create factory with default PreClassLoaderInitiators and ClassLoaderPreMortemCleanUps     final ClassLoaderLeakPreventorFactory classLoaderLeakPreventorFactory = createClassLoaderLeakPreventorFactory();
instead of
    // Create factory with default PreClassLoaderInitiators and ClassLoaderPreMortemCleanUps     final ClassLoaderLeakPreventorFactory classLoaderLeakPreventorFactory = new ClassLoaderLeakPreventorFactory();
where createClassLoaderLeakPreventorFactory() is a template method that my subclass can override as such:
    protected ClassLoaderLeakPreventorFactory createClassLoaderLeakPreventionFactory() {         final ClassLoaderLeakPreventorFactory classLoaderLeakPreventorFactory = new ClassLoaderLeakPreventorFactory();         classLoaderLeakPreventorFactory.removeCleanUp(KeepAliveTimerCacheCleanUp.class);         return classLoaderLeakPreventorFactory;     }
(Right now, extending ClassLoaderLeakPreventorListener to do this, requires dupilcating almost half of the code.)
Would you be open to such a change?

Hi @jbeckers - sorry for the late reply.
Thanks for the suggestion. I have now made such a change, however it is currently not yet released.


Release v0.1.0

@JuliaRegistrator register(branch="release/v0.1")

@JuliaRegistrator register(branch="release/v0.1")

Registration pull request created: JuliaRegistries/General/52614
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" c8cb84fcf7c95d72faaf7fb34ecefbd090195551
git push origin v0.1.0

@JuliaRegistrator register(branch="release/v0.1")

Registration pull request updated: JuliaRegistries/General/52614
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" e7ec1b5406d157c6f76e43b7620a054cd14df9b2
git push origin v0.1.0


[SourceKit] Make the NameLength of EnumElements take argument labels into account

This fixes an inconsistency where the argument labels of enum elements were included in the element's DisplayName because of #15562 but not taken into account for its NameLength.
Fixes rdar://40085232

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test

I wasn't familiar with this code when I made the changes in the linked PR, but I'm also not sure why extending the name of the enum element to the entire case declaration is correct.

Alright, thanks for clearing that up - and double thanks for un-cargo-culting the SourceKit changes.

@swift-ci Please smoke test


Add fixed network range on the local cluster and use Calico CNI

Changed the network IP range to a fixed range for easy debugging
Replaced kindnetd CNI with Calico for more features and stability

Closing for the time being as the Calico CNI is not a necessity.

Closing for the time being as the Calico CNI is not a necessity.


Support load config from .babelrc?

How about supporting load config from .babelrc? thus multiple environments (such as storybook) could use a same rc file.

It could be done but every develop using an .babelrc file would need to keep in sync is babel config with CRA.
The current CRA babel config is:
                customize: require.resolve(
                  'babel-preset-react-app/webpack-overrides'
                ),
                // @remove-on-eject-begin
                babelrc: false,
                configFile: false,
                presets: [require.resolve('babel-preset-react-app')],
                // Make sure we have a unique cache identifier, erring on the
                // side of caution.
                // We remove this when the user ejects because the default
                // is sane and uses Babel options. Instead of options, we use
                // the react-scripts and babel-preset-react-app versions.
                cacheIdentifier: getCacheIdentifier(
                  isEnvProduction
                    ? 'production'
                    : isEnvDevelopment && 'development',
                  [
                    'babel-plugin-named-asset-import',
                    'babel-preset-react-app',
                    'react-dev-utils',
                    'react-scripts',
                  ]
                ),
                // @remove-on-eject-end
                plugins: [
                  [
                    require.resolve('babel-plugin-named-asset-import'),
                    {
                      loaderMap: {
                        svg: {
                          ReactComponent: '@svgr/webpack?-svgo,+ref![path]',
                        },
                      },
                    },
                  ],
                ],

And also, craco babel support for Jest will not work if you use an babelrc file

I will close this issue since there is no activity


Status of the project -- release strategy?

Hi,
the last commit was quite some time ago, and the code seems to be in a good condition with only few minor open enhancement issues.
Maybe it would now be a good time to consider either putting it on pypi and getting it into conda-forge ?
This would make it easier for other packages to depend on it.
Thank you for your work,
Felix

Thanks! Yes, that would indeed be a good idea.
Unclear if we have anybody with available cycles to do this right now
unfortunately.
On Thu, Sep 19, 2024 at 11:35 AM Felix F Zimmermann <
@.***> wrote:

Hi,
the last commit was quite some time ago, and the code seems to be in a
good condition with only few minor open enhancement issues.
Maybe it would now be a good time to consider either putting it on pypi
and getting it into conda-forge ?
This would make it easier for other packages to depend on it.
Thank you for your work,
Felix
—
Reply to this email directly, view it on GitHub
https://github.com/flatironinstitute/pytorch-finufft/issues/106, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ7AC7Q4IGGF3K7HH2XUY3ZXKLERAVCNFSM6AAAAABOPP4KBOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUZTKOBQHE3DGNA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I can next week. Will need to make sure recent finufft changes didn’t break anything first

I just uploaded the current state of the repo to PyPI: https://pypi.org/project/pytorch-finufft/
@eickenberg if https://pypi.org/user/meickeick/ is you I can also add you to the pypi owners list. I also added a basic github action here to do releases, which has the proper permissions set up


Support versioning for packages

Use docs-generator for including TypeDocs of near-api-js and near-sdk-js in this repo

it seems that all the other Github actions that we had, (link checker, build check, spell checker) didn't run in this PR. 🤔
The Render preview wasn't generated either. I wonder what happened


Add grid custom filters

Adds the filter management and the dropdown list with defined filters to be applied in the displayed grid

merged in master


[HDInsight] Add two commands to support hdinsight node reboot feature

Description
Add two commands:

az hdinsight host list to support list the hosts of the HDInsight cluster
az hdinsight host restart to support restart specific hosts of the HDInsight cluster

Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

HDInsight

Could you add tests for these two commands?

Hi @MyronFanQiu  I have added the related tests. Could you please review again?

@haroldrandom @Juliehzl Please review this PR as the code onwer.


Add a tyxml interface

I will add an example tomorrow, It's designed to that you can do:
module T = Tyxml.Make(Tyxml_js.To_dom)

Related to #1.


Local Email Settings

I followed instructions and got this running locally.  Everything seems to be working, except how do you change the email settings so the software can use my email servers?

https://github.com/timeoff-management/timeoff-management-application/issues/455

يا له من جنون


*: setup CI

I've enabled branch protection and now following checks are necessary:

DCO
ci/circleci: build
ci/circleci: test


More removal functionality for DsChain implementations

remove_index removes chain at index
remove_value removes all matching values
remove_type removes all values of matching type

The issue here is that DsChain doesn't actually have any add or remove functionality.  Originally it had some support for adding links, but the problem was that anything that inherits this base type then inadvertently absorbs it.  So, for example, how does remove_type function in context of a stack?  There's probably a way forwards on this, but I think you probably want this added to DsLinkedList.


Change DisableView to match release notes

Looks like this was missed when changing redirect_url to success_url in
other views

Coverage remained the same at 95.874% when pulling 9a8875b3788b7ed97641e8da81b138c93b8d8daa on moggers87:missed_redirect_url into d6d9149410ef0850a320ce78e84d2a07c71d0a37 on Bouke:master.

Looks like an oversight indeed, thank you!


Add OSM extract settings

Checklist

[x] Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
[x] Any modified or new methods or classes have helpful JSDoc and code is thoroughly commented
[x] The description lists all applicable issues this PR seeks to resolve
[x] The description lists any configuration setting(s) that differ from the default settings
[x] All tests and CI builds passing

Description
Add OSM settings to deployment viewer to support changes in https://github.com/ibi-group/datatools-server/pull/298. (re #124)

Codecov Report

Merging #555 into dev will decrease coverage by 28.65%.
The diff coverage is 7.69%.

@@             Coverage Diff             @@
##              dev     #555       +/-   ##
===========================================
- Coverage   44.64%   15.99%   -28.66%
===========================================
  Files         314      314
  Lines       17138    16002     -1136
  Branches     5235     4868      -367
===========================================
- Hits         7651     2559     -5092
- Misses       8273    11467     +3194
- Partials     1214     1976      +762

Flag
Coverage Δ

#end_to_end_tests
?

#unit_tests
15.99% <7.69%> (-0.01%)
:arrow_down:

Impacted Files
Coverage Δ

lib/types/index.js
0.00% <ø> (ø)

lib/manager/components/DeploymentViewer.js
16.57% <7.69%> (-48.85%)
:arrow_down:

lib/manager/components/validation/TripsChart.js
0.00% <0.00%> (-80.40%)
:arrow_down:

lib/editor/util/objects.js
14.89% <0.00%> (-78.73%)
:arrow_down:

...nager/components/validation/ServicePerModeChart.js
0.00% <0.00%> (-78.27%)
:arrow_down:

lib/common/util/map-keys.js
25.00% <0.00%> (-75.00%)
:arrow_down:

lib/editor/components/EditorInput.js
0.00% <0.00%> (-72.79%)
:arrow_down:

lib/manager/components/HomeProjectDropdown.js
0.00% <0.00%> (-72.73%)
:arrow_down:

lib/editor/components/map/TextPath.js
0.00% <0.00%> (-70.00%)
:arrow_down:

...b/manager/containers/ActiveFeedVersionNavigator.js
0.00% <0.00%> (-70.00%)
:arrow_down:

... and 260 more

Continue to review full report at Codecov.

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

Updates:
Default

Override with URL

Exclude OSM

:tada: This PR is included in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[HELP] how to configure dialog which has multiple tabs.

Dialog was created with multiple tabs,

Not able to read the yaml.
demo:
  Componet:
     TabOne:
        type: TEXTFIELD
        label: label One
         value: Demo 1

Hi @DeChrish,
the structure of component configuration have to be in the following format:
<config-name>:
    <tab-name>:
        - type: <field-type>
          label: <field-label>
          value: <field-value>
        - ...
    <tab-name>:
        - ...
    ...

Please note the indentation (YAML structure is determined by it) and the dash sign (which indicates an array element).
Based on the above, your config should look like:
ttl_demo:
    General/Title:
        - ...
    Links:
        - ...
    ...

HI @mkrzyzanowski it works, thanks.
Yaml is added to configure the component,  how to validate the default value of the dialog?

Hi @marcinczeczko , While using YAML to configure the component, it take long time to identify the dialog (max 30-40 sec) then it configure based on the YAML. Am i missing anything ?

As for your first question, regarding validation of the default values: that's not supported in the current implementation. You test part of it indirectly when you are configuring the component, as it uses some of the mentioned labels in the process, except default values and tooltips.
I'd like to take a step back here and comment on that need. When testing the AEM authoring you are checking your custom bits of the platform, not the AEM itself - hence, you would not normally test the dialog rendering. It is based on component's configuration (_cq_dialog XML files) and if it is supposed to be tested in an automated way, I would recommend doing it on a lower level of the testing pyramid by validating the mentioned XML files, not the GUI layer.
As for the second part, if it's reproducible it might be related to some performance problems or miss-timed explicit waits - either way, a bug deserving a separate issue :).

Closing the ticket. If you have further questions, please let us know.

What if I dont have a TAB??


fixed .travis.yml

if we are switching to gradle then probably can hold off on the pom.xml change?


[Notion Block] Support Toggle notion block

Support Toggle notion block.
Here is reference: https://github.com/meursyphus/react-notion-custom/pull/9#pullrequestreview-2320838474
you should check guideline on https://github.com/meursyphus/react-notion-custom/blob/main/packages/react-notion-custom/CONTRIBUTING.md

this is resolved


Examples in examples/api cannot run because of a missed step while migrating to the declarative plugins {} block

Steps to reproduce

Open the examples/api project (master/beta/stable).
Run any example on the Android platform.

The issue is caused by this line in examples/api/android/app/build.gradle:
https://github.com/flutter/flutter/blob/2c473b33f335191e5f9f4b7028a0be46eff82d0c/examples/api/android/app/build.gradle#L67
It should be removed when migrating to the declarative plugins {} block.
This plugin should be moved to the bottom as well regarding to this instruction.
https://github.com/flutter/flutter/blob/2c473b33f335191e5f9f4b7028a0be46eff82d0c/examples/api/android/app/build.gradle#L7
Expected results
No issue found
Actual results
Warning: unable to detect project KGP version. Skipping version checking.
This may be because you have applied KGP after the Flutter Gradle Plugin.

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/thanhnhan/Documents/Development/Projects/Flutter/flutter/examples/api/android/app/build.gradle' line: 67

* What went wrong:
A problem occurred evaluating project ':app'.
> Could not get unknown property 'kotlin_version' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1s
Error: Gradle task assembleDebug failed with exit code 1

Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[!] Flutter (Channel [user-branch], 3.22.0-14.0.pre.58, on macOS 14.3 23D56 darwin-arm64, locale en-VN)
    ! Flutter version 3.22.0-14.0.pre.58 on channel [user-branch] at /Users/thanhnhan/Documents/Development/Projects/Flutter/flutter
      Currently on an unknown channel. Run `flutter channel` to switch to an official channel.
      If that doesn't fix the issue, reinstall Flutter by following instructions at https://flutter.dev/docs/get-started/install.
    ! Upstream repository https://github.com/lamnhan066/flutter.git is not a standard remote.
      Set environment variable "FLUTTER_GIT_URL" to https://github.com/lamnhan066/flutter.git to dismiss this error.
    • Framework revision 663be6ff4a (29 minutes ago), 2024-04-20 09:26:47 +0700
    • Engine revision 3db86b3cab
    • Dart version 3.5.0 (build 3.5.0-81.0.dev)
    • DevTools version 2.35.0-dev.8
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update
      checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/thanhnhan/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/thanhnhan/Library/Android/sdk
    • Java binary at: /Users/thanhnhan/Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15E204a
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Users/thanhnhan/Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] IntelliJ IDEA Community Edition (version 2023.3.2)
    • IntelliJ at /Users/thanhnhan/Applications/IntelliJ IDEA Community Edition.app
    • Flutter plugin version 77.0.1
    • Dart plugin version 233.13135.65

[✓] VS Code (version 1.88.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.84.0

[✓] Connected device (5 available)
    • sdk gphone64 arm64 (mobile)     • emulator-5554             • android-arm64  • Android 14 (API 34) (emulator)
    • iPhone (mobile)                 • 00008101-000468C02608001E • ios            • iOS 17.4.1 21E236
    • macOS (desktop)                 • macos                     • darwin-arm64   • macOS 14.3 23D56 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad     • darwin         • macOS 14.3 23D56 darwin-arm64
    • Chrome (web)                    • chrome                    • web-javascript • Google Chrome 124.0.6367.61

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

Reproducible using the steps outlined above.

flutter doctor -v
[!] Flutter (Channel stable, 3.19.6, on macOS 14.4.1 23E224 darwin-arm64, locale en-GB)
    • Flutter version 3.19.6 on channel stable at /Users/nexus/dev/sdks/flutter
    ! Warning: `flutter` on your path resolves to /Users/nexus/dev/sdks/flutters/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/nexus/dev/sdks/flutter. Consider adding /Users/nexus/dev/sdks/flutter/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/nexus/dev/sdks/flutters/bin/dart, which is not inside your current Flutter SDK checkout at /Users/nexus/dev/sdks/flutter. Consider adding /Users/nexus/dev/sdks/flutter/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 54e66469a9 (5 days ago), 2024-04-17 13:08:03 -0700
    • Engine revision c4cd48e186
    • Dart version 3.3.4
    • DevTools version 2.31.1
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /Users/nexus/Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.3)
    • Xcode at /Applications/Xcode-15.3.0.app/Contents/Developer
    • Build 15E204a
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Users/nexus/Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] IntelliJ IDEA Ultimate Edition (version 2023.2.5)
    • IntelliJ at /Users/nexus/Applications/IntelliJ IDEA Ultimate.app
    • Flutter plugin version 77.2.2
    • Dart plugin version 232.10286

[✓] VS Code (version 1.88.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.86.0

[✓] Connected device (5 available)
    • Pixel 7 (mobile)     • adb-28291FDH2001SA-5Lv71w._adb-tls-connect._tcp. • android-arm64  • Android 14 (API 34)
    • Nexus (mobile)       • 00008020-001875E83A38002E                        • ios            • iOS 17.4.1 21E236
    • Dean’s iPad (mobile) • 00008103-000825C811E3401E                        • ios            • iOS 17.4.1 21E236
    • macOS (desktop)      • macos                                            • darwin-arm64   • macOS 14.4.1 23E224 darwin-arm64
    • Chrome (web)         • chrome                                           • web-javascript • Google Chrome 124.0.6367.60

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

[✓] Flutter (Channel master, 3.22.0-14.0.pre.67, on macOS 14.4.1 23E224 darwin-arm64, locale en-GB)
    • Flutter version 3.22.0-14.0.pre.67 on channel master at /Users/nexus/dev/sdks/flutters
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 1a905d508d (21 hours ago), 2024-04-21 06:44:23 -0400
    • Engine revision 75ca2195c9
    • Dart version 3.5.0 (build 3.5.0-83.0.dev)
    • DevTools version 2.35.0-dev.8

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /Users/nexus/Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.3)
    • Xcode at /Applications/Xcode-15.3.0.app/Contents/Developer
    • Build 15E204a
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Users/nexus/Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] IntelliJ IDEA Ultimate Edition (version 2023.2.5)
    • IntelliJ at /Users/nexus/Applications/IntelliJ IDEA Ultimate.app
    • Flutter plugin version 77.2.2
    • Dart plugin version 232.10286

[✓] VS Code (version 1.88.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.86.0

[✓] Connected device (6 available)
    • Pixel 7 (mobile)                • adb-28291FDH2001SA-5Lv71w._adb-tls-connect._tcp. • android-arm64  • Android 14 (API 34)
    • Nexus (mobile)                  • 00008020-001875E83A38002E                        • ios            • iOS 17.4.1 21E236
    • Dean’s iPad (mobile)            • 00008103-000825C811E3401E                        • ios            • iOS 17.4.1 21E236
    • macOS (desktop)                 • macos                                            • darwin-arm64   • macOS 14.4.1 23E224 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad                            • darwin         • macOS 14.4.1 23E224 darwin-arm64
    • Chrome (web)                    • chrome                                           • web-javascript • Google Chrome 124.0.6367.60

[✓] Network resources
    • All expected network resources are available.

• No issues found!


PackageId:CPython39.Exe.x64;PackageAction:Install;ReturnCode:1603;

This issue has been moved from a ticket on Developer Community.

[regression]
在此处描述你的问题
===DO NOT EDIT BELOW THIS LINE===
PackageId:CPython39.Exe.x64;PackageAction:Install;ReturnCode:1603;

Original Comments
Feedback Bot on 12/20/2022, 00:14 AM:
(private comment, text removed)

Original Solutions
(no solutions)

duplicate of #7320


Trying to add new atlas to tileset shows "Open File(s)" dialog instead

Tested versions

Reproducible in: v4.2.1.stable.official [b09f793f5], v4.2.stable.official [46dc27791]
Not reproducible in: v4.1.3.stable.official [f06b6836a]

System information
Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 960 (NVIDIA; <IP_ADDRESS>01) - 13th Gen Intel(R) Core(TM) i5-13400 (16 Threads)
Issue description
Trying to add a new atlas source via the "+" button in the TileSet window opens the "Open File(s)" dialog instead of adding a new atlas source. Since both the text in the TileSet window as well as the official documentation state that this should indeed create a new resource I assume this is a bug (as opposed to a change that now requires the user to create the resource separately).
Behavior in 4.2.1 and 4.2.0:
https://github.com/godotengine/godot/assets/159484964/3f0e5810-3977-4c73-b49f-917052a6e34a
Behavior in 4.1.3:
https://github.com/godotengine/godot/assets/159484964/238e6f0e-8f0f-46ea-b8c5-29fbc2782a5e
Steps to reproduce

Create a new project
Create a new scene
Add a new TileMap
Add a new Tile Set to the TileMap
Open the TileSet window
Click on the "+" symbol
Click on "Atlas"

Minimal reproduction project (MRP)
4_2_1_TilemapTest.zip

This is by design to make it easier and quicker as you have to add a texture anyway (and might have fixed some bugs too)
I think changing this back would hurt usability and be a downgrade

maybe the title of the Window could be changed to something like "Select Texture for Atlas Tile Source" to make clear what you are trying to select here?

This is by design to make it easier and quicker as you have to add a texture anyway (and might have fixed some bugs too)
I think changing this back would hurt usability and be a downgrade
We should clarify the behaviour though in the documentation and editor

I respectfully disagree with you. I just got stumped on this for the last 20 minutes because the documentation says to press the + button the make a new one and the open files dialog just keeps opening up, so that hurt my usability.
I suggest the best solution would be to just add another button. Keep the + for new atlases, and add another file icon to open an existing one.


Create a new preview pane that shows the Node tree also a GLB exporter.

Also use npm dependencies to pull down Babylon.js instead of adding it to this project directly.

Wow, cool, I wasn't expecting this!  Before I dig into the code though, are you willing to send us a filled-out copy of the CLA (Contributor License Agreement)?  This is a document that basically says that while you keep the copyright on the code you wrote, you did intend to share it with us and you grant us the rights to use, modify, and redistribute the code.  You email it to<EMAIL_ADDRESS>with a note that it's for gltf-vscode.  Thanks!!

Hi @najadojo, did you fill out a CLA?  We can't take a pull request without this, unfortunately.

Working on the CLA... sorry for the delay.

I've just send in my CLA. I'll merge master and do a new commit shortly.

Thanks @najadojo, we received the CLA.

@HowardWolosky are you OK with switching Babylon to be an npm dependency?

I think it's a great idea.  It certainly simplifies the update step for that engine.  We should look at trying to do something similar for the other engines as well. It looks like we can do it for Three:

three
orbit controls
gltf2 loader

And I guess this would work for Cesium too?
Certainly doesn't need to be done as part of this PR, but we should open an item to do the work at some point.  Any way we can remove manual effort would streamline things.  This does put the onus on you though @emackey to be sure you're always running npm update before doing any release.  You might want to add that to PUBLISH.md as a reminder.

Bit new at using GitHub... are there code review comments I'm missing? What would be the next steps to merge this PR?  Thanks.

@najadojo Welcome!  This is an amazing contribution, and I'm really excited about the GLB export in particular, it fills a great need in the glTF ecosystem that the glTF Working Group has been discussing recently.
One concern I have is that it looks like it would be easy for existing GLB files to be overwritten without warning.  But the timing here is a happy coincidence, the VSCode team just last month added a shiny new file dialog API, including a window.showSaveDialog call that could be used to prompt for the GLB filename, defaulting to the name you've already calculated.  I presume the file dialog would automatically show an overwrite warning, as most do, but I haven't tried this myself yet.  A newer vscode API dependency is likely needed in package.json.  Here's a link to where save dialogs were just recently added to the awesome vscode-hexdump extension.
Other than that I think this is good to go.  Someday when I have more free time I may attempt to replace the HTML-based tree with VSCode's own tree, like the one used in vscode-zipexplorer.  But that's a project for another time.
@HowardWolosky did you want to add any other comments here?  I'll tweak the README myself, I think this just needs a save dialog and it's a go.

Oh cool I didn't know about that API. I was a bit unhappy with the filename selection and I did want to give the customer a way to make a selection so this is ideal.  I also have plans to implement a GLB importer that would create a collection of separate files described within. Then a customer could easily open the resulting gltf text document and use the rest of the extension's features.
I specifically decided not to use the vscode tree view because I have further plans with that as well. I'd like to make the various buffers that make up meshes browseable in a sort of table view like you'd see in a Object Table. I'm not really sure how I'm going to accomplish as yet so suggestions would be helpful.  Maybe using the tree view and show the buffers as documents as they are selected.

Sounds awesome!  One other suggestion:  When you start work on a new feature like GLB import, our usual best-practice is to create a new git branch named after the feature (such as glb-import or similar), and create the pull request from there.  Typically features come in on separate branches so they can run at a different cadence (for example, a node-tree branch could get reviewed and merged separately from a glb-export branch, etc).
In this case it's not needed of course, just push the save dialog changes to your master branch when ready so they get added to this PR which is already based on master.  My comments here are just for next time.

I haven't had the time to really dig into this change.  I think as long as @emackey has reviewed it and is ok with it, all seems good by me.

Cool.  Got an error when saving to another folder, it tried to load the .bin file from the selected output folder instead of the gltf source folder.

Fixed a few issues and I'm merging this.  Thanks so much @najadojo!

And this is published now as 2.0.7. 🎉


Convert production database to new process/template attributes

The templates and process attributes have changed. The production database needs to be converted to the new format. In addition the conversion script has steps that may not apply. We need to verify that steps that don't need to be run and remove them from the conversion script.

Done


Docker crashing MicroK8s kubelet

Hi,
I'm in the process of changing all of my docker deployments over to a microK8s cluster.
After successfully deploying the application in K8s  I go to my docker's application repository and run docker-compose down
This stops and removes the docker container but so far, every time I have done this ( 3 or 4 times now ) my kubelet changes to a FAIL! state and my node changes to NotReady
So far I've just been restarting the kubelet manually as my solution.
Host: Ubuntu 20.04
Docker: 20.10.6
MicroK8s: 1.20.6
inspection-report-20210517_023626.tar.gz

Can you try adding --advertise-address=<IP_ADDRESS> to the file /var/snap/microk8s/current/args/kube-apiserver?

Same for me. Try switching to microk8s v1.21. The microk8s daemon will still being down but the running pods/deploymenst/services will still be working.

@MrCorncob if you can try adding the arguments i mentioned here https://github.com/ubuntu/microk8s/issues/2269#issuecomment-842353921 see if it still restarts the daemons.

Can you try adding --advertise-address=<IP_ADDRESS> to the file /var/snap/microk8s/current/args/kube-apiserver?

After adding this snippet to the file, i stopped microk8s and then started it again to make sure it applied.
This seemed to put the kubelet in a crash loop with status '255'

I can't remember what to put into these values.
Can replacing advertise-address with bind-address=<IP_ADDRESS> instead?
Sorry bou that.  Right now, im guessing that the apiservice kicker is detecting a new network interface then restarts the apiserver atleast thats what i see in the logs...

I can't remember what to put into these values.
Can replacing advertise-address with bind-address=<IP_ADDRESS> instead?
Sorry bou that. Right now, im guessing that the apiservice kicker is detecting a new network interface then restarts the apiserver atleast thats what i see in the logs...

So I tried this and rebooted MicroK8s, this time everything was running but I was unable to access the cluster ( not even using the kubectl built into MicroK8s )
After resetting the settings in the file back to my default I tried to reproduce the issue using the same compose file that was crashing the kubelet and it wasn't happening this time around so I'm wondering if it wasn't actually docker causing it before and if it was just a coincidence it was happening at the same time

My gut tells me that the apiservice kicker seems to be restarting kubelite.  Some were able to alleviate this by adding --bind-address-<IP_ADDRESS> forcing the apiservice kicker to ignore any network changes hence reducing kubelite restarts.  There's also a PR (https://github.com/ubuntu/microk8s/pull/2217) to add a lock file ${SNAP_DATA}/var/lock/no-cert-reissue instead of changing the kube-apiserver args.

I am also seeing something similar, we use docker-in-docker for integration inside pods on microk8s, every time the integration pod calls docker, kubelet crashes.

I just tested adding --bind-address=<IP_ADDRESS> to /var/snap/microk8s/current/args/kube-apiserver and whenever my pod tries to start another container using Docker in Docker inside the container, the kubelet still crashes. For the PR for that lock file, is that something I need to add to my nodes myself? Is that PR present in latest/stable?
Thanks!

@andrew-landsverk-win which version are you using?  Since adding the arg --bind-address and you are still facing the issue, then it must be something else other than the apiservice-kicker.
Can you share your inspect tarball? And also any steps to reproduce?
Thanks

Sorry for the late response! I discovered that my VMs were not on our fast storage, so I have remedied that. I am using latest/stable which looks like it's tracking 1.21 right now.
I will post back here if I still see issues.
Thanks!

with --bind-address=<IP_ADDRESS> and after updating to 1.21, I havent ran into the issue since ( also have not tried 1.21 without the bind address either )

Gonna go ahead and close this since updating fixed my issue and there hasnt been any activity in almost a month. If any other commentators have a persisting issue and are unable to update, I would recommend creating a new ticket and reference this one

Just to add, --bind-address=<IP_ADDRESS> also worked for me in the latest v1.30.1


ArgumentOufOfRangeException although passed value is valid

Affected Version: >= 6.0.1 (5.x works)
Stacktrace:
Unhandled exception. System.ArgumentOutOfRangeException: MaxCount should be greater than or equal to 1. (Parameter 'options')
Actual value was 1.
   at AsyncKeyedLock.AsyncKeyedLockDictionary`1..ctor(AsyncKeyedLockOptions options)
   at AsyncKeyedLock.AsyncKeyedLocker`1..ctor(AsyncKeyedLockOptions options)

It is obvious from the stacktrace that the check seems to be behaving incorrectly.
The value that was passed is 1 and is greater than or equal to 1 obviously.
Code that leads to the error:
new AsyncKeyedLocker<string>(new AsyncKeyedLockOptions(1, 25))

Thank you. The issue has been fixed and is available in 6.0.2.

Credited as contributor @ https://github.com/MarkCiliaVincenti/AsyncKeyedLock/blob/master/CONTRIBUTORS.md
Thanks again!


The middleware ordering in http router is not correct

🐞 Bug Report
Affected Services

 The issue is located in: all edgex-go services
Is this a regression?

 No
Description and Minimal Reproduction
In the router.go of each service, the functions are end with:
	r.Use(correlation.ManageHeader)
	r.Use(correlation.OnResponseComplete)
	r.Use(correlation.OnRequestBegin)

The execution order is not right.  OnRequestBegin should be added before OnResponseComplete
Also, OnResponseComplete would be invoked before the response complete

I misunderstood the code.  The ordering is correct, because OnResponseComplete calls next.ServeHTTP(w, r) inside, and OnRequestBegin will be completed first


Emergency accounts - non-expiring password

Guidance should also include for Break Glass accounts on this page:

Exclude from MFA
Exclude from PIM
Set password to never expire (only through PowerShell last time I checked)

[Enter feedback here]

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

ID: cfac0ecf-e5a9-c5ff-f8c2-ce27789708f5
Version Independent ID: 0f5e0cc9-a54f-a5c8-192d-d60a6a4db3ff
Content: Azure Active Directory security defaults
Content Source: articles/active-directory/fundamentals/concept-fundamentals-security-defaults.md
Service: active-directory
Sub-service: conditional-access
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@ziggyngmailcom Thank you for the feedback. We are actively investigating and will get back to you soon.

@ziggyngmailcom What exactly are you trying to accomplish?
You can't create custom Conditional Access policies to exclude specific accounts when using security defaults. You would probably not have PIM either if you are using security defaults.

#reassign:@MicrosoftGuyJFlo

#please-close


Meta: Documentation

Provide FTorch implementation guidance to allow implementation, by researchers, of different NN architectures

This is heavily covered by https://github.com/DataWaveProject/CAM/pull/5
And more widely by Jacks work from January to interface FTorch more generally to the CESM suite.


Heroku Build failed - Two different lockfiles found: package-lock.json and yarn.lock

Hi!
I'm getting the message  "Build failed - Two different lockfiles found: package-lock.json and yarn.lock" when deploying the application on Heroku.
Heroku says to remove yarn.lock, but there is no such file.
Does anyone know what I need to do to resolve this?
I'm working with code from v2017.09 release.
Thanks.

Likely you have a leftover file from a previous build. Indeed Saleor no longer has a yarn.lock file as we no longer require yarn.

Thanks for the answer. I was making a mess with the branches here and there was actually this file. Problem solved.


More descriptive section link error messages

One quick example:
When the linker dies with error "Section FOO could not be loaded at $1337", it would be nice to see the name of the section that would overlap FOO (and this directly causes the error).

Also, RAM sections are allowed to overlap (not sure if it requires one of the sections to have size 0).  Is this intended?

Sounds like a helpful idea! 😄 It might take a bit of effort to implement, but I imagine this would save quite a lot of time.

Re: your second comment (I'll assume you're talking about fixing two RAM sections to the same address), I doubt that's intentional in general. However, if a section hasn't actually reserved any memory (even if it's been fixed at a position), I can see why that would avoid an error, even if they appear to overlap looking at your assembly.
While it's a fringe case, I can see why it might be helpful to catch these errors early, before you add more things to that section. If you can reproduce this (especially if it's with two non-empty sections), could you produce a minimum working example and add a separate issue?

Yes, it is an useful thing to have. However, the code isn't really ready for this, the file src/link/assign.c will need some rework.
Regarding the overlaps, maybe we could have a warning for all 0 byte sections instead. I don't think the linker should treat an empty region as a non-empty one and say there is an overlap when there really isn't. What about having an empty section just for a label? That's what they are doing here: https://github.com/rednex/rgbds/issues/233

Does #434 improve / fix this?

After merging #434 and testing the following simple program, it appears that the error message hasn't been improved.
SECTION "a", ROM0[0]
ds 2

SECTION "b", ROM0[1]
ds 1

The problem is that, in this trivial case, it's clear which sections overlap. But, if the section that fails to be placed is floating, trying to tell all the candidate locations that failed would result in an error log comparable to C++ template errors, which seem to be unanimously hated.
What would be a better solution?
(To be more down-to-earth, check function placeSection in src/link/assign.c)

Could you post example messages for the alternatives you suggest?

The only case in which it seems possible to output something meaningful is when the failed SECTION has a fixed bank and address. Is that enough, though?

Better than nothing.

And an absolute pain to implement!


CSS Variable for padding on class pd-list-item-content and pd-list-item-expandable-content

Recently, we received the results of a UX review on our end, which indicated that the padding within the pd-list-item and pd-list-item-expandable is excessive.

Is it possible to add a CSS variable that we can use to adjust the size of the respective padding? This would apply to the pd-list-item-expandable component as well.

there is a css-property --pd-list-content-padding on the pd-list component with which you can set the padding of the content. Maybe this is what you are looking for?

Thanks for your response! We noticed that you have the option to change the Pd-List padding with that CSS variable. The wish would be to change the padding on the pd-list-item-content class and the matching class from the pd-list-item-expandable.
.pd-list-item-content {
    padding: 0.75rem; <---
    flex: 1 1 auto;
}

yes, i see! i added a --pd-list-item-padding css variable with which you can control the padding of the items in the pd-list-item and the pd-list-item-expandable.
As you write the padding of the pd-list-item was exessive, do you have a new (better) default value for it? now it was 0.75rem.
for the expandable-item we leave the default as it is?

We discussed in the team, and you can leave the default as it is on both components. As long as we have the option to change the values with the CSS variable, it is fine.

Ready to test in 3.0.4 👍


Symlink libs folder

For improved dev experience:

symlink ../monorepo to .node_modules/@avo when developing locally
install @avo in production from package or in this early stage the public repo

Was not able to solve this with npm/yarn or pnpn.
-> Created a script(symlink_libs.sh) that replaces ./node_modules/@avo/monorepo with symlink to ../monorepo.
-> just run pm run symlink to execute script


adding missing translations for de locale

This PR adds missing translation for de locale.

Coverage remained the same at 90.404% when pulling b605b08f19e00d2b0a074ca677b3cb5fd6ced2ca on add-missing-translations-v1-0-7 into ccf77d97ae247791ad9cf1f34570394e089608c8 on master.

Coverage remained the same at 90.404% when pulling b605b08f19e00d2b0a074ca677b3cb5fd6ced2ca on add-missing-translations-v1-0-7 into ccf77d97ae247791ad9cf1f34570394e089608c8 on master.

Thank you for your contribution.


Cannot Delete Plugin

I have been trying to delete Multiverse in it's entirety for a while now. It seems like no one has had this problem so i'll put it in myself. I've deleted everything in the Multiverse folder except for one stubborn file that refuses to go away. It's scripts.bin. On my Anvilnode server, every time i try to delete it, it fails. Can anyone help me out?

You need to delete the .jar file for Multiverse-Core. We're sad to see you go :(


MultiVideoCapture with USB Hub

Hello! I really appreciate the work you've done to simplify the PySpin wrapper.
I have a setup with two FLIR BFS cameras that are connected to a USB hub (they're also both secondary cams with a TTL pulse generator attached). The SynchronizedVideoCapture (SVC) ) class worked wonderfully for them, but I have a slight issue with the MultipleVideoCapture (MVC) class.
I noticed that when I try to initialize the cams using MVC, they won't open. This is because I connected my cams to an external USB hub I bought on amazon. If I plug the cameras directly to my laptop, the MVC class correctly initializes the cameras.
The reason why I want to use MVC is to have a quick cam feed before running the real experiment ~ this way I can make sure the cams are in focus. If you have any ideas for how to make MVC work with a USB hub, I think others will appreciate it too!
I'm using Windows 10, python=3.9
This is what I tried running: (only works when USB's plug directly into my laptop)
import EasyPySpin
import cv2

cap = EasyPySpin.MultipleVideoCapture(0, 1)
cap.isOpened()

This is the other way I tried: (which works with USB hub)
import EasyPySpin
import cv2

serial_number_1 = "23473323" # pupil
serial_number_2 = "21126272" # face

cap = EasyPySpin.SynchronizedVideoCapture(None, serial_number_1, serial_number_2)
cap.isOpened()

Using serial numbers for MVC didn't work.

Nvm, it was a connection issue with the USB hub. It works now.


Dynamic batch_size

Feature request for dynamic batch_size to work around SQS limitation of batch size max == single message size max
http://docs.aws.amazon.com/sdkforruby/api/Aws/SQS/Client.html#send_message_batch-instance_method

The maximum allowed individual message size is 256 KB (262,144 bytes).
The maximum total payload size (i.e., the sum of all a batch's individual message lengths) is also 256 KB (262,144 bytes).

related issue: https://github.com/logstash-plugins/logstash-output-sqs/issues/10

Since 4.0.0, there is a check in place for ajusting the batch size.


Remove ServiceComb/paas-lager to go-chassis

Delete all the ServiceComb dependency in kubeedge in the PR.

/cc @qizha @sids-b @rohitsardesai83 @kevin-wangzefeng

/lgtm

Thanks @fisherxu , lets update the kubeedge repository vendor with these changes


Fix memory leak on registry read error

The changes brought by https://github.com/emeric-martineau/wsl-gui-tool/pull/6 lead to a memory leak when a registry reading error occurred. The function LoadWslOneDistributionFromRegistryById tries to read a distribuiton list from the registry and once the registry has an incorrect value the ERegistryException is thrown. At this stage, the Result variable should be freed but it doesn't.
This PR fixes the memory leak by catching the registry exception, freeing the variable and rethrowing the exception again.

Hello @skoro ,
thanks for your PR.


Modernize ES6

Convert to ES6 style class
Removed bluebird in favor of native Node.js Promise
document functions
Fixed test so they exit properly

@mjsalinger if you'd like to add me as a contributor to this project I'd be happy to go through all the pull requests and issue and resolve them. I know this project has some security implications so if you'd rather not I understand. That said, it would be great for this project to move forward as you make updates to oauth2-server

I really like your upgrade, gonna fork myself a copy out of your fork, because I would also bump oauth2-server to 3.1.1 at least


Dashboard auto refresh control was removed

Because Cloud users complained about inadvertently racking up large bills due to automated query refresh, this control has been removed.  Docs need an update to reflect this for OSS and Cloud.
Relevant URLs
https://docs.influxdata.com/influxdb/v2.0/visualize-data/dashboards/control-dashboard/#select-auto-refresh-interval

Any chance that access to this control will be moving into an admin setting?

@PrplHaz4 -- we are discussing the mechanisms by which auto refresh could be re-introduced.    While, yes, that is user error -- we are re-evaluating what criteria should be used to allow for auto refresh.  For example:

no keyboard/mouse inputs for x mins
presentation mode only
admin controls to select the options (# of mins to timeout, availability of the feature, etc.)

Would welcome your feedback on the above...

I can see all of those being applicable in some manner - and it does sound risky to re-introduce a feature that could have runaway charges without any guard rails.
I think we'd prefer a combo of approaches - allowing admins to make it available (globally or for specific users), then a sensible default sleep timeout and/or refresh interval for "live" dashboards/presentation mode.


Added blog post about Kubernetes on MIPS

Signed-off-by: Dominic Yin<EMAIL_ADDRESS>

/assign @jimangel

@sftim Thank you for your advice, content updated.

/assign @onlydole

@onlydole Nice work! Thank you very much!

@sftim Thanks, and the image has been updated.

/lgtm
/assign @mrbobbytables

@onlydole sorry didn't see the hidden conversations before, all resolved now.

No worries! Thanks @ydcool!
/lgtm

ping @onlydole @jimangel @mrbobbytables for approve

Sorry for the delay in getting to review -- was out of the office for a bit.
From a technical perspective, everything looks good.
I've updated the dates in the filename to bump them to today and approved with a hold. Once @castrojo or @kbarnard10 signs off the hold can be lifted and it should be published.
/assign @kbarnard10 @castrojo
/approve
/hold

Hm, weird - it didn't add approve on here...trying again:
/approve

@mrbobbytables / @kbarnard10 - any objections to approving this post (we should be good on permissions now!)

Lets schedule this for Wednesday the 15th. I'll update the posting date and we can merge.

/lgtm
/hold cancel


Icon not showing

Please check your icons don't load at all, no error, nothing.Just blank

Hi @a1erons
I have just checked the icons, and they show up as expected. Can you share your implementation?


WDT Timeout Issue

Congrats on a nice project!
I am trying to port the code to a ESP32C3 (I have a few, and I've used them in several other projects), and I've commented pretty much everything except the core functionality (no ArduinoOTA, no NeoPixel, no MQTT data send), just some Serial.println() debug messages for now.
I'm trying to talk to one (of a pair) of Growatt SPF3000TL inverters.
But if I flash the code (stripped down as above) I get "Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)." (error repeated verbatim for future searches). I noticed you mentioned a WDT timeout in one of the videos, which got my attention, so hoping you may have some more insights.
My Timer ISR (same as your master code) calls ReadHoldingRegisters() in the ino, which invokes growattInterface.ReadHoldingRegisters(json) in growattInterface, of which the relevant entry point is:
uint8_t growattIF::ReadHoldingRegisters(char* json) {
  uint8_t result;
  ITimer0.stopTimer();
  result = growattInterface.readHoldingRegisters(setcounter * 64, 64); //<< WDT panic is occurring here
  // result = 0;
  ITimer0.restartTimer();

If I comment the readHoldingRegisters line and uncomment the result=0; it runs fine.
Of course there could be several reasons something is timing out there - communications problem with the TTL to RS485 board (mine looks identical to the one you used), failed communications with the Growatt, etc, etc.
I would really like to drill down in to the growattInterface.readHoldingRegisters(setcounter * 64, 64) call to try and figure out in more detail exactly what is timing out, so I can narrow it down, but I'm lost in the overloading of ReadHoldingRegisters (either capitalized or not) in the ino, and also in the growattInterface class.
So a specific question: where do I find the code that growattInterface.readHoldingRegisters(setcounter * 64, 64) invokes? grep etc is not helping.
I really like the clean ISR approach to invoking the code, but I'm stuck trying to use it at the moment.
Any insights really appreciated!

Thanks, it's a good point, the ITimer0.stopTimer() in my code only stops that specific ISR from getting double triggered if it takes too long. But rereading your code, I see that you turned off the interrupt WDT itself. I may have to try that on the ESP32C3, but it may be problematical with other timing critical things going on.
Where's the source for the growattInterface.readHoldingRegisters(setcounter * 64, 64) method?
I must be missing something, I can't find it.
On a very rough guesstimate the Growatt modbus dialog must take something like 500mS (64 x 16 bit registers @ 9600, ignoring overhead), so we're looking for relatively a lot of time.
Thanks again

I've been able to get past the WDT timeout issue by refactoring the code as a couple of Tasks on top of the Espressif FreeRTOS core, and I'm using a queue to pass the json from a Growatt Modbus query task to an MQTT post task.
This seems fine so far, and solves the WDT timeout issue, without having to disable the WDT. These tasks run at a lower priority than core processes (WDT etc), and so can take as long as they need. This means though the Modbus code may get interrupted by the core intermittently, so a concern is that this may trip up the serial timing, though I have not seen evidence of that yet, and since it's only 9600 there's hope that it won't.
I believe all Espressif SoCs (ESP...) use their version of FreeRTOS under the hood, so this approach might be applicable to the ESP8266 as well.
How did you figure out the SLAVE_ID of the Growatt?
I am now getting Invalid SlaveID back from the Modbus code, and with weak documentation struggling to figure out the valid slave ID, short of taking the time to brute force it.

The default slave ID is 1. But you can change it on the screen. I checked the documentation, it does not mention "modbus" or "slave id" anywhere, but this is the closest setting I could find:

Thanks so much.
I added temporary Serial.println()'s for the slaveID that I query and the slave ID sent back from the Growatt in ModbusMaster, and I am getting a changing ID back - on one one occasion I sent 1 and I actually got slaveID 1 back, but on every other occasion I've gotten 2, 3, etc.
So I'm now thinking that the serial comms is not working the way I think it's working for whatever reason (timing inside the FreeRTOS Task?).
I've ordered an RS485 to USB dongle, and I'll try talking to the Growatt using mbpoll from my laptop. This should remove at least some of the uncertainty around new code, comms, etc. leaving only the Growatt talking to known code.

That is very interesting. There is CRC check in the modbus communication, so if the serial data is off, the CRC check would fail and the code would give an invalid CRC error. But checking with mbpoll and a USB dongle is a good workaround to check what is wrong.

It's a good point about the CRC check. I've now had a chance to try the USB dongle, and interestingly I am getting almost identical behavior. So this says to me that at least the immediate problem is not in the code, it is somewhere else (although there are few other things to suspect!).
I do wonder whether 9600 is the correct speed - I know in the master code you commented "do not change", but I'm running out of things to suspect now.
Rather than load up this thread with posts not directly related to the subject code, I have posted a question over here.
I won't close this thread yet, pending any learnings from the post linked above, which may help others with implementing the code.

Thanks, weird. Please let me know if you find out the solution. I see no reason why Growatt would do it any other way, but is it possible that the communication is not Modbus? When I see RS485 I always assume Modbus, but it does not necessarily have to be (sorry did not read the entire documentation). Also try using different flow control, like not 8 bits, maybe change the stop bit and parity. And yes you can play around with the baud as well.

So I figured out the communications.
It seems this Growatt SPF3000TL inverter has to be cold-rebooted when the RS485 Modbus slave ID is updated, otherwise it looks like it listens for the new address, but responds with the old address in the header, resulting in the Modbus master seeing an invalid slave ID. My inverters are in a production setting already, and so I had avoided rebooting them until now.
Also, it was a good suggestion to look at flow control, stop bit, parity etc - I had assumed (my bad) that 8N1 was the default, but it is not the default for mbpoll and it looks like the CRC errors were caused by a serial protocol mismatch.
I've now got far enough that I have read registers back from my Tasks version of the project code and Serial.println-ed the json. So I am moving on to passing the json to the MQTT posting Task, and tidying everything up now.
Thanks again for helpful suggestions!

Wonderful, I am glad that all this worked out. Never thought about the cold-boot issue, good catch.

Thanks. I was considering whether to generate a PR for this, but the problem is the ESP32 code ends up being pretty different (HardwareSerial, task-based code structure), and when I tried, I ended up adding many compiler switches, so I don't think it's helpful.
But having said that, suggestions welcome.