python310Packages.mkdocs-redirects: 1.0.4 -> 1.1.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.mkdocs-redirects is: "Open source plugin for Mkdocs page redirects"
meta.homepage for python310Packages.mkdocs-redirects is: "https://github.com/mkdocs/mkdocs-redirects"
meta.changelog for python310Packages.mkdocs-redirects is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.0.6 with grep in /nix/store/2bqswwcq25q35c2nskvvai3mgypgkfkd-mkdocs-redirects-1.0.6
found 1.0.6 in filename of file in /nix/store/2bqswwcq25q35c2nskvvai3mgypgkfkd-mkdocs-redirects-1.0.6

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.mkdocs-redirects
python39Packages.mkdocs-redirects

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/2bqswwcq25q35c2nskvvai3mgypgkfkd-mkdocs-redirects-1.0.6 \
  --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 python310Packages.mkdocs-redirects https://github.com/r-ryantm/nixpkgs/archive/5545e785679c9df834ded99020b9062ee6ec99ab.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/2bqswwcq25q35c2nskvvai3mgypgkfkd-mkdocs-redirects-1.0.6
ls -la /nix/store/2bqswwcq25q35c2nskvvai3mgypgkfkd-mkdocs-redirects-1.0.6/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

2 packages built:

python310Packages.mkdocs-redirects
python39Packages.mkdocs-redirects

Maintainer pings
cc @tfc for testing.

Result of nixpkgs-review pr 187514 run on x86_64-linux 1

2 packages built:

python310Packages.mkdocs-redirects
python39Packages.mkdocs-redirects

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.mkdocs-redirects is: "Open source plugin for Mkdocs page redirects"
meta.homepage for python310Packages.mkdocs-redirects is: "https://github.com/mkdocs/mkdocs-redirects"
meta.changelog for python310Packages.mkdocs-redirects is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.1.0 with grep in /nix/store/8fdxnzrs68bh4rax4rhhlrzmb7l06cl9-mkdocs-redirects-1.1.0
found 1.1.0 in filename of file in /nix/store/8fdxnzrs68bh4rax4rhhlrzmb7l06cl9-mkdocs-redirects-1.1.0

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.mkdocs-redirects
python39Packages.mkdocs-redirects

Instructions to test this update (click to expand)

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

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/8fdxnzrs68bh4rax4rhhlrzmb7l06cl9-mkdocs-redirects-1.1.0
ls -la /nix/store/8fdxnzrs68bh4rax4rhhlrzmb7l06cl9-mkdocs-redirects-1.1.0/bin

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

2 packages built:

python310Packages.mkdocs-redirects
python39Packages.mkdocs-redirects

Maintainer pings
cc @tfc for testing.

Result of nixpkgs-review pr 187514 run on x86_64-linux 1

2 packages built:

python310Packages.mkdocs-redirects
python39Packages.mkdocs-redirects


[Here's LIVe] Anthony Joshua vs Daniel Dubois LIVE STREAMS ON TV CHANNEL 21 September [2024]

17 sec ago-All the key details for this huge heavyweight fight as Anthony Joshua and Daniel Dubois headline an incredible fight card on DAZN tonight.
Posted on September 21, 2024
Daniel Dubois and Anthony Joshua will clash in a heavyweight title fight tonight, as part of the exciting Riyadh Season.
Dubois was recently upgraded to IBF world champion after Oleksandr Usyk vacated the belt and he'll make his first defence against Joshua.
The card, at a record breaking sold-out Wembley Stadium also sees the likes of Tyler Denny, Anthony Cacace, Josh Warrington and Josh Kelly on the bill, while Oasis frontman Liam Gallagher will perform.
Here's everything you need to know ahead of AJ v Dubois.
When is the Joshua vs. Dubois fight?
The fight takes place on Saturday, September 21, as Dubois defends his newly inherited belt against two-time world champion Joshua. The fight card begins at 4 p.m UK time, with the main event ringwalk expected around 10 p.m.
Date: Saturday, September 21
Start time: 4 p.m. UK / 11 a.m. ET
Main event ringwalks (approx): 10 p.m. UK / 5 p.m. ET
Where is the Joshua vs. Dubois fight?
The English capital, London, hosts AJ against Dubois at a sold-out Wembley Stadium. The home of the England football team, and regular host of NFL London matches, will boast a record-attendance for a boxing contest at the stadium of 96,000.
It will be the first time defending champion Dubois has fought under the famous arch, while AJ returns for a fourth time to Wembley, where he is undefeated.
How can I watch AJ-Dubois fight and what does it cost?
DAZN pay-per-view has The Riyadh Season: Joshua vs Dubois event live and in full in over 200 countries for £19.99. Click here for more information and to buy . This also includes a seven-day free trial of the DAZN platform.
All the key details for this huge heavyweight fight as Anthony Joshua and Daniel Dubois headline an incredible fight card on DAZN tonight.
All the key details for this huge heavyweight fight as Anthony Joshua and Daniel Dubois headline an incredible fight card on DAZN tonight.
The fight takes place on Saturday, September 21, as Dubois defends his newly inherited belt against two-time world champion Joshua.


US-20: Adding a Vehicle Zone to a Dealership

AP-45 This acceptance test should validate the following:

Vehicle Zones must be integrated with Google Maps
A zone must have a name and can have a description
A zone must cover an area on the map

Approved


Test: reveal in test explorer needs polish

Have a test file open

Right click on a test -> reveal in test explorer it is nicely shown
Now scroll a bit in the test explorer, and trigger again the reveal action -> it is not shown 🐛

Also reveal in test explorer should focus and select the item in the tree to make it obvious which one it is. Similar to how explorer does it for "reveal in sidebar"

Reveal actually didn't do anything before, so I'll use this as a feature-request for verification. Summary:

You can right click test icons in the gutter and "reveal" a test
This should open the test explorer, if it's not already open, and show the test
In the event that tests are not yet discovered (e.g. in a fresh window in the vscode window) the reveal action should happen once the requested test is discovered and displayed in the tree

Thanks, I'll verify this.


npx prisma generate very slow

Bug description

npx prisma generate

Environment variables loaded from .env
Prisma schema loaded from prisma\schema.prisma
then loading ....
,very slow, i don't konw to fix this problem
Why is it sometimes fast and sometimes slow
and i m already do npm install success,
How to reproduce

Expected behavior
No response
Prisma information

Environment & setup

OS:
Database:
Node.js version:

Prisma Version

Please set the DEBUG=* environment variable, run again and paste the full output you are getting.
If you can see what takes long, please also let us know.

https://registry.npmmirror.com/binary.html?path=prisma

M1 Max macos
Node v16.15.0

very slow, how to download Prisma like this way?
registry=https://registry.npm.taobao.org
sass_binary_site=https://npm.taobao.org/mirrors/node-sass/
phantomjs_cdnurl=https://npm.taobao.org/mirrors/phantomjs/
electron_mirror=https://npm.taobao.org/mirrors/electron/
puppeteer_download_host=https://npm.taobao.org/mirrors

chromedriver_cdnurl=https://npm.taobao.org/mirrors/chromedriver
operadriver_cdnurl=https://npm.taobao.org/mirrors/operadriver
selenium_cdnurl=https://npm.taobao.org/mirrors/selenium
node_inspector_cdnurl=https://npm.taobao.org/mirrors/node-inspector
node_sqlite3_binary_host_mirror=https://npm.taobao.org/mirrors

prisma blocked
node_modules/.pnpm/@prisma+engines@2.31.0-32.2452cc6313d52b8b9a96999ac0e974d0aedf88db/node_modules/@prisma/engines: Running postinstall script...
node_modules/.pnpm/@prisma+engines@3.14.0-36.2b0c12756921c891fec4f68d9444e18c7d5d4a6a/node_modules/@prisma/engines: Running postinstall script...
node_modules/.pnpm/@prisma+engines@2.31.0-32.2452cc6313d52b8b9a96999ac0e974d0aedf88db/node_modules/@prisma/engines: Running postinstall script, done in 163ms
node_modules/.pnpm/@nestjs+core@8.4.6_95015279855349ef3fc3851e24d75fe7/node_modules/@nestjs/core: Running postinstall scrnode_modules/.pnpm/@nestjs+core@7.6.18_eb32d6534d538289125509d6da94e7b2/node_modules/@nestjs/core: Running postinstall script, done in<EMAIL_ADDRESS>Running postinstall script, done in 40ms
<EMAIL_ADDRESS>Running postinstall script, done in 32ms

@AoiIsMine
On npx prisma generate, Prisma needs to download the engine binaries if they haven't been downloaded yet. Usually it should be quite fast, but it may take a while if you have issues with your internet connection, or if you are in a country that filters the incoming traffic and has slow connection to the outside world. Please let us know if neither of these is the case but you still experience the issue.
@jsonchou
The environment variable you are looking for is PRISMA_ENGINES_MIRROR.
Please see the docs for more details: https://www.prisma.io/docs/reference/api-reference/environment-variables-reference#downloading-engines

Happens for me after upgrading from prisma 3 to 4.  Debug output is:
  prisma:loadEnv  project root found at C:\Users\tm\Documents\0_Git\03_Uptraded_Native\NativeBackend\message\package.json +0ms
  prisma:tryLoadEnv  Environment variables loaded from C:\Users\tm\Documents\0_Git\03_Uptraded_Native\NativeBackend\message\.env +0ms
Environment variables loaded from .env
Prisma schema loaded from prisma\schema.prisma
  prisma:getConfig  Using getConfig Wasm +0ms
  prisma:getConfig  config data retrieved without errors in getConfig Wasm +5ms
  prisma:getDMMF  Using CLI Query Engine (Node-API Library) at: C:\Users\tm\Documents\0_Git\03_Uptraded_Native\NativeBackend\message\node_modules\prisma\query_engine-windows.dll.node +0ms
  prisma:getDMMF  Loaded Node-API Library +4ms
  prisma:getDMMF  unserialized dmmf result ready +25ms
  prisma:getDMMF  dmmf retrieved without errors in getDmmfNodeAPI +9ms
  prisma:generator  prismaCLIDir C:\Users\tm\Documents\0_Git\03_Uptraded_Native\NativeBackend\message\node_modules\prisma +0ms
  prisma:generator  prismaClientDir C:\Users\tm\Documents\0_Git\03_Uptraded_Native\NativeBackend\message\node_modules\@prisma\client +1ms
  prisma:generator  baseDir C:\Users\tm\Documents\0_Git\03_Uptraded_Native\NativeBackend\message\prisma +0ms
  prisma:generator  typescriptPath C:\Users\tm\Documents\0_Git\03_Uptraded_Native\NativeBackend\message\node_modules\typescript +13ms
  prisma:GeneratorProcess  2023-01-30T14:24:40.352Z prisma:client:generator  requiredEngine: libqueryEngine +0ms
  prisma:getGenerators  neededVersions {
  "ceb5c99003b99c9ee2c1d2e618e359c14aef2ea5": {
    "engines": [
      "queryEngine",
      "libqueryEngine"
    ],
    "binaryTargets": [
      {
        "fromEnvVar": null,
        "value": "windows"
      },
      {
        "fromEnvVar": null,
        "value": "debian-openssl-1.1.x"
      }
    ]
  }
} +0ms
  prisma:getGenerators  {
  generatorBinaryPaths: {
    queryEngine: {
      windows: 'C:\\Users\\tm\\Documents\\0_Git\\03_Uptraded_Native\\NativeBackend\\message\\node_modules\\prisma\\query-engine-windows.exe',
      'debian-openssl-1.1.x': 'C:\\Users\\tm\\Documents\\0_Git\\03_Uptraded_Native\\NativeBackend\\message\\node_modules\\prisma\\query-engine-debian-openssl-1.1.x'
    }
  }
} +348ms
  prisma:getGenerators  {
  generatorBinaryPaths: {
    libqueryEngine: {
      windows: 'C:\\Users\\tm\\Documents\\0_Git\\03_Uptraded_Native\\NativeBackend\\message\\node_modules\\prisma\\query_engine-windows.dll.node',
      'debian-openssl-1.1.x': 'C:\\Users\\tm\\Documents\\0_Git\\03_Uptraded_Native\\NativeBackend\\message\\node_modules\\prisma\\libquery_engine-debian-openssl-1.1.x.so.node'
    }
  }
} +3ms

Afterwards it gets stuck. Internet connection is not too bad. Any idea?

Wuhu! Solution was that in my prisma file I had
generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-1.1.x"]
}

Changed it to
generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "linux-musl"]
}

In my case I had to run pnpm i --save-dev @prisma/client. I am using PNPM and prisma was already installed

In my case I had to run pnpm i --save-dev @prisma/client. I am using PNPM and prisma was already installed.

me too.


Saleor API does not work when build on Apple M1

There is a problem with libpq on Apple M1 silicone.
When I tried to run migrations
$ docker-compose run --rm api python3 manage.py migrate

I got error like this:
pg_connect(): Unable to connect to PostgreSQL server: SCRAM authentication requires libpq version 10 or above.

TLDR
Force building on x86 architecture
export DOCKER_DEFAULT_PLATFORM=linux/amd64

Explanation
There are a few solutions to this described in here and here
I think that some mention in README would be great.

Using export DOCKER_DEFAULT_PLATFORM=linux/amd64 caused another issue for me, npm install step hanged forever :(

Hi, I tested it with M1 Pro and I don't face any issues.
npm step should be also resolved, frontend repositories have been updated a lot.
Please open new issue if you face any problems


Limit in "Upload CSV data"

Make sure these boxes are checked before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if any
[x] I have reproduced the issue with at least the latest released version of superset
[x] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
superset 0.25.5
Expected results
Import the 27000 lines from my csv input data. I
Actual results
superset/lib/python2.7/site-packages/werkzeug/wrappers.py:1116: UserWarning: The "session" cookie is too large: the value was 275662 bytes but the header required 26 extra bytes. The final size was 275688 bytes but the limit is 4093 bytes. Browsers may silently ignore cookies larger than this.
samesite=samesite
[24/May/2018 10:39:13] "POST /csvtodatabaseview/form HTTP/1.1" 302 -
2018-05-24 10:39:17,241:INFO:werkzeug:XX.XX.XX.XX - - [24/May/2018 10:39:17] "GET /csvtodatabaseview/form HTTP/1.1" 200 -
Steps to reproduce
This problem occurs when you try to upload a large csv file. It's annoying because most of the time we do not connect directly to the database but load an extraction of it.
How can we get around this ?
Regards.

The solution should be looked in the browser that you are using (that is the answer on the same question I got). I am having the same issue with Superset==0.25, but with previous ==0.24, everything was fine. Taking this into account, I am not sure that the problem is in the browser, but in the new version of Superset (possibly some restrictions).

Hello,
thanks for your interest in this subject.
I also thought at first that it could come from a limitation in superset configuration.
I looked in werzeug conf as it appears in the log message (see above my first post).
So i tried to change the sset/lib/python2.7/site-packages/werkzeug/wrappers.py value from 4093 to 0 as explained in the comments but it does not work either.
#: Warn if a cookie header exceeds this size. The default, 4093, should be
#: safely `supported by most browsers <cookie_>`_. A cookie larger than
#: this size will still be sent, but it may be ignored or handled
#: incorrectly by some browsers. Set to 0 to disable this check.
#:
#: .. versionadded:: 0.13
#:
#: .. _`cookie`: http://browsercookielimits.squawky.net/
max_cookie_size = 0

meet the same question:
Superset version
superset 0.25.5
Expected results
Import the 10000 lines from my csv input data.
Actual results
UserWarning: The "b'session'" cookie is too large: the value was 640742 bytes but the header required 26 extra bytes. The final size was 640768 bytes but the limit is 4093 bytes. Browsers may silently ignore cookies larger than this.
  samesite=samesite

Steps to reproduce
This problem occurs when you try to upload a large csv file.  my csv file is about 1GB, i cut part of it(about 2MB) ,first, when i upload the file,  the web page shows:
ERR_RESPONSE_HEADERS_TOO_BIG

then the console log shows:
UserWarning: The "b'session'" cookie is too large: the value was 640742 bytes but the header required 26 extra bytes. The final size was 640768 bytes but the limit is 4093 bytes. Browsers may silently ignore cookies larger than this.

Has anyone met this before? what is your solution? please help me ,thanks~
Regards.

Not this exact cookie error that others are getting, but I get 504/502 Bad Gateway errors when uploading a large csv file. I saw that the Gunicorn worker was terminating:
[2018-10-24 16:45:45 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:93)
/usr/local/lib/python3.5/dist-packages/superset/db_engine_specs.py:148: DtypeWarning: Columns (158,236,357,366,483,498,499,550,584) have mixed types. Specify dtype option on import or set low_memory=False.
  df = pandas.concat(chunk for chunk in chunks)
/usr/local/lib/python3.5/dist-packages/superset/db_engine_specs.py:148: DtypeWarning: Columns (17,158,236,366,483,498,550,583,584) have mixed types. Specify dtype option on import or set low_memory=False.
  df = pandas.concat(chunk for chunk in chunks)
Loaded your LOCAL configuration at [/etc/superset/superset_config.py]
/usr/local/lib/python3.5/dist-packages/superset/db_engine_specs.py:148: DtypeWarning: Columns (158,236,353,354,357,366,483,498,550,583,584) have mixed types. Specify dtype option on import or set low_memory=False.
  df = pandas.concat(chunk for chunk in chunks)
/usr/local/lib/python3.5/dist-packages/superset/db_engine_specs.py:148: DtypeWarning: Columns (9,158,236,260,288,366,483,498,547,550,583,584,599) have mixed types. Specify dtype option on import or set low_memory=False.
  df = pandas.concat(chunk for chunk in chunks)
[2018-10-24 16:45:45 +0000] [93] [INFO] Worker exiting (pid: 93)
[2018-10-24 16:45:46 +0000] [102] [INFO] Booting worker with pid: 102

So I increased the timeout via
superset gunicorn \
              -w 3 \
              -k gevent \
              --timeout 120 \
              -b <IP_ADDRESS>:8088 \
              --limit-request-line 0 \
              --limit-request-field_size 0 \
              superset:app

to 600s and now I can upload 21mb files. But unfortunately we have to keep increasing this timeout for larger files.

I've encountered this problem recently in Superset v1.5.0. In my case, the root cause seems to be encoding incompatibility.
The size of csv file to be uploaded was about 2.1MB (12000 rows) and the error log looked the same as others:

/home/me/venv38/lib64/python3.8/site-packages/werkzeug/wrappers/base_response.py:468: UserWarning: The "b'session'" cookie is too large: the value was 19232 bytes but the header required 40 extra bytes. The final size was 19272 bytes but the limit is 4093 bytes. Browsers may silently ignore cookies larger than this.

There's something wrong with the size of the file (2M is not large enough), so I tried to upload a small csv with only 10 lines in it to shrink the cookie size and got the real error in the response:

(1366, "Incorrect string value: '\xE4\xBD\xA0\xE5\xA5\xBD' for column 'name' at row 1")

With a little googling, this error might be related to inserting rows containing non-latin charater into latin encoding backend MySQL db. After changing default charset, csv upload worked like a charm.


Add trouble shoot section about DNS private-zone

You Need 3 Records in the DNS, this is not documented :

asaInstanceName.private.azuremicroservices.io => service runtime 'kubernetes-internal' ILB IP
asaInstanceName-myAppName.private.azuremicroservices.io => service runtime 'kubernetes-internal' ILB IP
asaInstanceName.svc.private.azuremicroservices.io => service runtime 'kubernetes-internal' ILB IP - REQUIRED to communicate with managed services such as Config-Server-

When using Custom DNS, it is :
myAppName.contoso.com
Then you can add 1 and only 1 DNS entry  *.contoso.com

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

ID: e5b5424a-b4cd-10bc-4839-b0a0e04d60ae
Version Independent ID: 246ba42e-d932-1f95-8520-36680f70dca1
Content: Troubleshooting Azure Spring Apps in virtual network
Content Source: articles/spring-apps/troubleshooting-vnet.md
Service: spring-apps
GitHub Login: @KarlErickson
Microsoft Alias: karler

@ezYakaEagle442
Thanks for your feedback! We will investigate and update as appropriate.

Will probably also need to be changed then here: https://learn.microsoft.com/en-us/azure/spring-apps/access-app-virtual-network?tabs=azure-CLI#create-dns-record

also a test record should be added, see https://github.com/ezYakaEagle442/azure-spring-apps-petclinic-mic-srv/blob/azure/iac/bicep/modules/asa/dns.bicep#L236
resource asaAppsTestRecordSet 'Microsoft.Network/privateDnsZones/A@2020-06-01' = {
  name: '${azureSpringAppsInstanceName}.test'
  parent: asaPrivateDnsZone
  properties: {
    aRecords: [
      {
        ipv4Address: appsAksLb.properties.frontendIPConfigurations[0].properties.privateIPAddress
      }
    ]
    cnameRecord: {
      cname: azureSpringAppsInstanceName
    }
    ttl: 360
  }
}

doc updated
#please-close


feat: support matchStandaloneSnapshot

This is an initial work towards #100

[x] Backward compatible
[ ] Test edge cases
[x] Update docs
[x] Unit testing
[x] Can we drop code duplication (?)

Hi @gkampitakis!
Thanks for putting this together. I was in the midst of looking for a way to save snapshot files with a .json extension and found your PR :)
Do you have a timeline around releasing this change?
Thanks again!

Hi @gkampitakis!
Thanks for putting this together. I was in the midst of looking for a way to save snapshot files with a .json extension and found your PR :)
Do you have a timeline around releasing this change?
Thanks again!

Hey @jeremyhcho, thanks for your interest. I have been quite busy this week, but hopefully I will make progress and manage to merge it this weekend if I don't encounter any issue as this pr is mostly done 😄 . If you want to test it and provide any feedback you are welcome to try it with
go get github.com/gkampitakis/go-snaps@matchStandaloneSnapshot


Possible memory leaks

Hello, first of all thanks for this great library not so usual in JS.
We are using pannellum to interactively display different panoramas alternatively in the same page. Each time we want to display a panorama we create a viewer like this:
viewer = pannellum.viewer('panorama', config);
However, it seems that most of the memory used is never freed. Looking at the code we can see that none of the allocated WebGL objects are freed (textures, buffers, etc.). Indeed, although JS objects are probably freed by the garbage collector in my experience there is no garbage collector in WebGL and you need to release the memory by yourself. Maybe its by design because in the destory() method of the renderer the WebGL canvas is destroyed, however I am not sure it will ensure the WebGL objects to be destroyed too. Actually by testing this on multiple browser it seems they are not.
We did some hack in order to retrieve some memory and make our app usable on mobile devices with few memory by calling destroy() manually at some point and adding inside the method the following code:
for (var i = 0; i < program.currentNodes.length; i++) {
           if (program.currentNodes[i].texture) {
               gl.deleteTexture(program.currentNodes[i].texture)
           }
}

We will try to contribute by providing a better solution but any help or advice is welcome. We believe the WebGL canvas should be globally allocated by the library, such as the shaders. Then the renderer object should only manage the objects used to display a panorama and correctly release all of them on destroy.
By the way we are using the multires mode.

WebGL objects are freed when the corresponding JavaScript object is garbage collected. However, when this garbage collection happens is based on system memory usage, not GPU memory usage, so one can run out of GPU memory.
I just committed 53c6cf85f7eb7c1accf07ab5fd2e23d6251c5151, which explicitly frees multires textures when their parent nodes are destroyed; this might help reduce GPU memory usage. Unfortunately, I don't know of any tools to profile WebGL GPU memory usage to test if it helps. The commit also fixes a DOM object and event listener leak, although I doubt the leak was causing a problem.
A globally allocated canvas is not an option, since this would prevent one from having multiple viewers on the same page. That being said, it should be possible, and would be preferable, to reuse the canvas in a particular viewer instance between scene changes instead of creating a new one each time the scene is changed.

Thanks for this rapid fix, actually when I said WebGL objects I effectively meant GPU-side objects.
You are right for a globally allocated canvas, in this case keeping one canvas per renderer seems mandatory. However, it should be possible to change the panorama config on the fly in a viewer so that we don't need to recreate everything to display a new image. Indeed, creating/destroying WebGL context on the fly is probably not a recommanded practise although it should work in theory.
Is there already a way with panellum to change the viewed image inside a viewer without the need to create a new instance  ?

If you have a list of the panoramas when the viewer is created, the tour syntax can be used (see example). Dynamically adding to this list isn't currently supported. The loadScene method can then be used to switch between the images.

OK this might be a viable solution because our list of panoramas is static but can be big (~ 20). Using the tour syntax are panoramas loaded/unloaded on-demand when calling loadScene ?

Yes, they are.

The renderer is now reused between scenes (see 38250c1d15d4ee3c792ae442336c53f637893f7f).


public interface for offset resetting

This pull request adds a public interface to the consumers that allows client code to set the current partition offsets to whatever they choose. Previously, this had to be done via a semi-public undocumented interface as detailed in this issue.
Given these changes, the new workflow for specifying offsets from which to consume looks like this:
consumer = topic.get_simple_consumer(consumer_group="testgroup")
partition_offset_pairs = [(p, get_starting_offset_for_partition(p)) for p in consumer.partitions]
consumer.reset_offsets(partitions=partition_offset_pairs)

The only issue I see with this method is that the consumer has a chance to start fetching messages between get_simple_consumer and reset_offsets. To get around this,  we could accept the partition_offset_pairs in get_simple_consumer, but that would require some way to obtain a list of partitions before actually instantiating a consumer. This sounds like a road I'd rather not go down, so the question is: how bad is it that it's impossible to start the consumer at an arbitrary offset that's not the head or tail of the partition? My gut tells me it doesn't matter and this solution is ok. Let me know what you think, @kbourgoin and @yungchin.

Cool cool, this is a feature I've good use for.

The only issue I see with this method is that the consumer has a chance to start fetching messages between get_simple_consumer and reset_offsets.

Ah, good point - I hadn't realised that when I posted on #187. So iiuc, that means if you start the consumer, then change the offsets, you might get a message from consume() at a different offset, because that got on the queue inbetween? That could be confusing. Would it be possible to flush the queues on all partitions passed to reset_offsets()?

we could accept the partition_offset_pairs in get_simple_consumer, but that would require some way to obtain a list of partitions before actually instantiating a consumer

That wouldn't be completely terrible either. Presumably, someone using this feature has some other place where they store offsets (I've an app where the offsets sit in postgres), and so they would usually know which partitions they want to begin with.
Although... it might get messy when the number of partitions is changed (by a cluster operator). If you then have to provide a list of partitions+offsets on init, you then can't make it grab the new partitions. So I guess for that scenario your current solution is better: you can grab whatever partitions there are (ie don't specify a list on init), and then for the ones you already knew about you can reset the offsets.
Note to self: I think I have to handle reset_offsets() in #176, if it's going to be a public method. Otherwise, the rdkafka consumer would completely ignore changed offsets after start().

I'm not totally convinced that there's a good reason to allow setting offsets on __init__, but I do think it's a smart idea to have reset_offsets always flush the internal queues when called by a user. When called internally in response to an error, it shouldn't, but this can be handled with a kwarg.

I'm not totally convinced that there's a good reason to allow setting offsets on __init__

Yes, no indeed - after re-reading my earlier ramble, I agree :)

I've added the option to lock and flush the partition queues during an offset reset. This means that users no longer need to manually pause consumption before calling reset_offsets. In implementing this, I also discovered a bug: if consume is called when there are some messages in the queue and after reset_offsets (_reset_offsets in current master) has been called, the partition's internal offset counter (last_offset_consumed) will be reset to match the message just returned from consume. That means that the offset set by reset_offsets will be effectively overwritten and the offset will appear not to have been reset. It's quite possible that this is the bug we've been seeing in production in which not all offsets are reset when deploying with reset_offsets_on_start.
To fix this, we now lock all fetcher threads and clear the per-partition message queues before resetting offsets so that any subsequent calls to consume  will start from the offset intended by reset_offsets, not from the offset of some other message hanging around in the queue.

This is ready for review @yungchin @kbourgoin. I'll be testing it against real streams as soon as possible, too.

Ok, so basically I've only lazy complaints about the function signature :)
The lack of exceptions I agree is not a regression from current master, so it makes sense to save them for a separate ticket, and as for how it looks under the hood otherwise: no complaints at all.

Awesome, thanks for the feedback. Your comments did make me realize it's no good to expose OwnedPartition to the client, so I need to figure that out.

It turns out that kafka-python allows this by promising to fetch the given offset next, not by actually committing the given offset to kafka. This is a problem because it creates a mismatch between the offset stored in kafka and the offset stored in the consumer; this is contrary to the design we've tried to maintain in pykafka so far.
Given that we'd like to commit offsets as soon as possible to kafka, we could try simply sending the user-supplied offsets to kafka during reset_offsets in an OffsetRequest. Unfortunately, the OffsetRequest only accepts timestamps, not actual offset values. When supplied with a timestamp it doesn't like, the request returns with an error code of 0 and an empty list for the offset. This seems to be a bug or at least a poor design choice in kafka.
It occurs to me that we could allow the user to supply either timestamps or actual offset values to reset_offsets. If the request succeeds and returns an offset (the dual error condition that we apparently have to check), we're all good. If it returns the empty offset list, we can simply set the consumer's internal offset to the supplied value and continue on. This will mirror the behavior of kafka-python and provide a bit more versatility.

This is now ready for review from @yungchin and @kbourgoin. @yungchin, this hasn't changed a ton since you looked at it, but I fixed some deadlocks and improved the interface for user-supplied offsets.

Cool, very happy with the addition of held_offsets. The deadlock fix looks perfectly good too (it did take me quite some time to get my head around that commit - it's become quite a challenge to reason about where we may grab and release fetch_lock!)
The new way of handling both timestamps and actual offsets seems a neat solution to me. I should add though that I don't feel particularly qualified to comment on that bit, given that I've only a poor understanding of Kafka's OffsetRequest semantics so far. Probably best if @kbourgoin can give that a read too.
I've added one new note (see above), which seems important for repeating failed requests. Other than that, all happy!


Update version: bornova.numara version 3.20.1

Pull request has been created with WinGet Automation :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/112979&drop=dogfoodAlpha

@wingetbot run


Observable testing

Adds unit tests for observable operations withErrorHandler and withLoadingBar

Tests will fail because of an error in withLoadingBar.ts. It's fixed in 150b19c


[webview_flutter] Addition of WebView Scrolling

Description
I have rebased my code on top of the latest master which contains #2533
These code changes were done in conjunction with @EitanSchwartz owner of the other PR.

This is a more idiomatic dart approach
Contains the ability to get the scroll extents.
Ability to disable the scrollbar visibility.
Fixes DPI issues with previous PR.

Related Issues

#2533

Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
[ ] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[ ] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the [Flutter Style Guide].
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[ ] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
[ ] I updated CHANGELOG.md to add a description of the change.
[x] I signed the [CLA].
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Just rebased my previous work. Test cases are required and need to be reviewed before merge.

@slightfoot It looks like there are format errors. Can you fix them and then add test(s) for the changes? I think it should be good after that.

Hi @slightfoot, are you still working on this?

@cg021: Yes, I can update to master so it can be merged.

Based on the comments above it sounds like this is still a WIP, so I'm going to mark this as a draft; please feel free to remove the draft designation once it's ready for review.


Update dependencies, actions steps, and usage for v2-maint

What type of PR is this?

maintenance

What this PR does / why we need it:
Like the title says, to keep up with [gestures wildly in all directions].
Which issue(s) this PR fixes:
N/A

@Juneezee @meatballhat  This PR should not have been submitted as is, and should not have pass review. A single commit that contains changes to go.mod, go.sum, .github/workflows/ and testdata/expected-doc-full.man is just poor quality, and could even have been the vehicule for evil things (thinking about xz).
I'm definitely worried about the maintenance of this project if such poor work pass validation. This project is now a huge danger to the Go ecosystem.
Cc: @dearchap

@dolmen Hello! I think I need some help understanding the risks 🤔

As a user of this module who tries to keep track of changes in dependencies before upgrading (and not blindly apply Dependabot changes), I appreciate to be able to read the Git history and understand what is happening.
Maybe I just would like to see:

more verbose commit messages. In this case, I would have been worth mentioning why the file in testdata had to be modified
less unrelated changes in a single commit: the workflows changes are independent of the Go dependency upgrade, so there should have been 2 separate commits

@dolmen I fail to understand why as a user of this library this matters to you at all. I mean sure most issues/PRs could do with better descriptions etc but that would be from a point of a developer who isnt familiar with the codebase/workflow at all. In general all the devs on this repo strive to maintain good practices and we generally make sure everyone is one same page. Reg dependencies we try to be minimally dependent on external libraries as this library is a framework on top on which cmd line tools(in conjunction with other packages) are built on. Of course we have to keep up to date with latest go versions more for security fixes than for any go version specific feature. We cant just keep the project stagnant by using a 1-2 year old go version for workflow. if you have any issues with these approaches I highly suggest you fork this repo and maintain it as per your requirements

I understand of joy of reading well written changelogs and commit messages, but that doesn't help on hard days.
@dolmen yes, without people like you asking, the quality of commit messages will be a bit relaxed. However, if you want to make the change, some stuff from https://handbook.gitlab.com/handbook/values/#assume-positive-intent might be helpful.
I guess you don't have time to chase the maintenance of yet another package, and that, of course, brings frustration. But if you consider this  to be an opportunity to learn about Go and spend some time socializing for good, then maybe asking your questions like "why the change to tests is needed" directly, will be make your next day brighter and more secure.

My frustration comes from the fact that, at work, I have to maintain alone about 30 services which depend on urfave/cli. I'm not yet done on migrating from v1 to v2, and now v3 is there. Of course that is just one of the dependencies I have to monitor (I have submitted #1847 a few months ago to reduce that load, and I still have to port that to v3). So I'm probably too touchy about commit quality when I review change before upgrading my dependencies. But I realize I have been too far in complaining on a closed PR: none of this frustration should be of the concerns of the maintainers.
So I apologize for having gone much too far in raising my concerns about readability of commits here. I should just have kept those to myself. A merged PR is not the right place to push for higher standards, and I should not have involved so many people.


ValueError: bytes object is too large

Description
I've been getting a "ValueError: bytes object is too large" error while using lightgbm with dask. How can I fix it?
Reproducible example
from dask import array as da
train_df, val_df = get_train_val_data('2020-01-01', '2020-02-28', time_gap = 5, daily_fold=0, daily_k_fold=2, intraday_fold=0, intraday_k_fold=2)
train_chunks = min(100000, int(train_df.shape[0]/16))
val_chunks = min(100000, int(val_df.shape[0]/16))
Xy1 = da.from_array(train_df[selected_feats.ALL_FEATS+[selected_feats.TARGETS[0],]].values)
Xy2 = da.from_array(val_df[selected_feats.ALL_FEATS+[selected_feats.TARGETS[0],]].values)
X1, y1 = Xy1[:,:-1].rechunk(train_chunks), Xy1[:,-1].rechunk(train_chunks)
X2, y2 = Xy2[:,:-1].rechunk(val_chunks), Xy2[:,-1].rechunk(val_chunks)
print(X1.compute_chunk_sizes(), y1.compute_chunk_sizes())

dask_model = lg.DaskLGBMClassifier(num_leaves=1024, learning_rate=0.02, n_estimators=1000, colsample_bytree=0.7,
                                       n_jobs=300, silent=False)
dask_model.fit(X1, y1, eval_set=[(X2, y2)], eval_metric='auc', early_stopping_rounds=15)

output
dask.array<rechunk-merge, shape=(6107340, 1002), dtype=float32, chunksize=(100000, 1002), chunktype=numpy.ndarray> dask.array<rechunk-merge, shape=(6107340,), dtype=float32, chunksize=(100000,), chunktype=numpy.ndarray>
Finding random open ports for workers
Traceback (most recent call last):
  File "/media/st2000/workspace/darkquant/darkquant/auto_trader/ashare/alpha_v10c/tree/dask_lg_train.py", line 138, in <module>
    dask_model.fit(X1, y1, eval_set=[(X2, y2)], eval_metric='auc', early_stopping_rounds=15)
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/lightgbm/dask.py", line 736, in fit
    **kwargs
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/lightgbm/dask.py", line 626, in _lgb_dask_fit
    **kwargs
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/lightgbm/dask.py", line 447, in _train
    for worker, list_of_parts in worker_map.items()
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/lightgbm/dask.py", line 447, in <listcomp>
    for worker, list_of_parts in worker_map.items()
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/distributed/client.py", line 1596, in submit
    actors=actor,
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/distributed/client.py", line 2594, in _graph_to_futures
    dsk = highlevelgraph_pack(dsk, self, keyset)
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/distributed/protocol/highlevelgraph.py", line 124, in highlevelgraph_pack
    return dumps_msgpack({"layers": layers})
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/distributed/protocol/core.py", line 184, in dumps_msgpack
    payload = msgpack.dumps(msg, default=msgpack_encode_default, use_bin_type=True)
  File "/home/hadoop/anaconda2/envs/pytorchenv/lib/python3.6/site-packages/msgpack/__init__.py", line 35, in packb
    return Packer(**kwargs).pack(o)
  File "msgpack/_packer.pyx", line 286, in msgpack._cmsgpack.Packer.pack
  File "msgpack/_packer.pyx", line 292, in msgpack._cmsgpack.Packer.pack
  File "msgpack/_packer.pyx", line 289, in msgpack._cmsgpack.Packer.pack
  File "msgpack/_packer.pyx", line 225, in msgpack._cmsgpack.Packer._pack
  File "msgpack/_packer.pyx", line 258, in msgpack._cmsgpack.Packer._pack
  File "msgpack/_packer.pyx", line 225, in msgpack._cmsgpack.Packer._pack
  File "msgpack/_packer.pyx", line 225, in msgpack._cmsgpack.Packer._pack
  File "msgpack/_packer.pyx", line 225, in msgpack._cmsgpack.Packer._pack
  File "msgpack/_packer.pyx", line 196, in msgpack._cmsgpack.Packer._pack
ValueError: bytes object is too large

Environment info
lightgbm==3.2.1
dask==2021.01.1
python==3.6.8

Thanks for raising an issue @nerdylinius. This issue has been resolved in a recent release. Can you upgrade your dask and distributed versions to the latest release (version 2021.04.1)?

@jrbourbeau unfortunately, version 2021.04.1 is not supported by python 3.6， and it is not convenient for me to update python from 3.6 to 3.7+

In that case can you try 2021.03.0 (that's the last version to support Python 3.6)?

@jrbourbeau I have tried 2021.03.0, but nothing changed

Hmm sorry to hear that. I believe this should be resolved by https://github.com/dask/dask/pull/7525 which was included in the 2021.04.1 release. However, given that you're on Python 3.6 I would recommend rolling back dask and distributed versions until the you get to a version that predates is bug that https://github.com/dask/dask/pull/7525 fixes. Unfortunately, I'm not sure what version that is off of memory.

@jrbourbeau thank you any way, I will try 2021.04.1 when I update python from 3.6 to 3.7+

Sounds good 👍 Let us know if you're still experiencing this issue once you're on 2021.04.1


Forwarding  HTML mails gives wrong formatting

If I forward HTML mails the receiver get an unreadable mail (it basically shows the quotedprintable text). I use the php mail()  to send mails.

seems like the problem comes from using international characters in the subject. It gets encoded with utf8 and the msg body is encoded with quoted printable....something gets broken along the way.


Too many connection error on Postgres

After connecting with the adapter, prometheus pods are not stable, restaring too many times. Not able to connecto to postgres database using a client, I keep on getting "Too many connetions" error.
adapter image:   timescale/prometheus-postgresql-adapter:0.4.1
pg-postgres image: timescale/pg_prometheus:0.2.1

Can you share the parameters that you are passing in when you start timescale/prometheus-postgresql-adapter:0.4.1 often times its a bad parameter that will cause it to try and start then fail.  Also pull the newest from our repo (0.5.0)... Also one other thing to check when you pass in the parameters you should use -pg-host= and not -pg.host (dashes not dots for all parameters) as this will cause the pod to fail to start.
let me know how it goes


exiftool: migrate to Homebrew

The exiftool was somehow missing from the list in #15603. It is already available in homebrew/core (exiftool.rb). It is cmd line only and can be built from source.
Homebrew does not use the latest version, but only those marked as "production release". But it seems also not to be too old.
@AnastasiaSulyagina what do you think?

Looks like formula to me, 👍

Also in favour. And if need be, the development version can always be added to the Formula.

Create ad PR to add the development version to the Formula (#3636).
It can be installed using brew install exiftool --devel.

The exiftool was somehow missing from the list in #15603.

Either the formula or the cask must have been added after I generated the list. We should probably update it.


Boolean argument truncation

A boolean argument evaluating to FALSE is truncated in the formatted string to 'FALS'.

Possible fix by expanding the length of the temporary string to store the boolean result.
Otherwise, the strcpy may not have the correct size argument.


⚠ ClamAV has degraded performance

In a531ae5, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 57 ms

Resolved: ClamAV performance has improved in c5d2cb5.


Add blog post for upcoming<EMAIL_ADDRESS>patch release

for review, with changes curated from apache/cordova-android#555

Is this WIP or you finished?
If you finished, there are a lot of changes missing
Incorrect default sdk version issue fix (PR #495) & update comments in build.gradle (PR #496)
Remove obsolete check for JellyBean to work properly on Android Pie (GH-534) (PR #544)
GH-539 & GH-540 fix destination path fallback & fix for source-file with app target-dir, with unit test updates (PR #542) (540 is on the list, but 539 isn't)
add missing cast for cdvMinSdkVersion (GH-551)
Multiple build-extras.gradle locations (GH-552)

My bad, just marked as WIP until I fix it!

I fixed the blog post, would appreciate a quick review (expecting to publish patch release and blog post later today).

Some of the changelog items link to PRs, some to items.
When JIRA was a thing, they all linked to the issue they fixed. Now we don't always have issues, and it is not really defined how to handle this. In my opinion it makes sense to link all to the PR, as the PR usually includes a link to the issue it closes. Agree? Or issue and PR both in a specific way?

In my opinion it makes sense to link all to the PR, as the PR usually includes a link to the issue it closes.

I'm fine to do it that way for now, would like to see feedback from others.

A proper "Squash and merge" commit message for example includes the PR number in the commit message: cordova-android 7.1.3 blog post (#911) (for this PR). Maybe we should use this template, link the #911 to the PR and add an issue in front if available?

departure from convention of using CB-??? or GH-??? that I saw elsewhere, looks like this came from Apache convention
just using #??? is not so good since we have a toolset with quite a few different repos. I would favor something like apache/cordova-android#550 to refer to PR #550 on cordova-android, like how GItHub references issues & PRs.
moving the reference from the beginning to the end is yet another departure

I just made the changes requested by @janpio. I think the requested changes make sense, and just a plain #??? reference is fine if the document refers to changes on only one project. Will merge later today if there are no further objections.

Thanks @jcesarmobile & @janpio for reviewing. I will merge this tonight when I publish the patch release.

Good points @brodybits. Let's keep it as you changed it for now - and move this into a later discussion about how we build our changelogs somewhere else.


Create a new category for CRM platform.

I guess is necessary to create a new category for this sort of platform as Salesforce, Netsuite, Zoho, SAP and so on.

Is this work is done or pending I will be glad to have an opportunity to workon this.

@manish2022-creator actually is still pending.


[suggestion] Hint Feature

First, Sorry for my bad english.
As title says, I think this game will be better if add hint button to all level for those who keep submitting wrong answer.
The detailed description and sample image of the hint feature is as follows:

When player click hint button that looks like above image, show popup window that contains phrase that has a hint to solve easily.
In conclusion, I want to ask if my team can develop this feature.
Also, if there's any suggestion in this feature, please let me know.
Thank you.

I thought about translating, First of all, how about temporarily put Google translation results for languages other than Korean and English?
I think my team can translate Korean and English.
I expect someone to contribute to other languages later.

Hi @thomaspark I'm sorry I keep mentioning you. If you OK, please answer if I can either proceed as suggested above or not.

Hey @qowlz, I'd like to delay this feature for now, since it will introduce a lot of additional work in terms of designing good hints that I can't prioritize, plus making the translations.

I understand. then, I'll close this issue for now.


Page background does not transition

Hi, I'm using Next.js with the same configuration in the Next.js example in the README, and the background of the page does not seem to transition. I couldn't get it to transition using Tailwind without Nightwind, either, but I see https://nightwindcss.com/ has a transition. Is that a custom thing?

nightwindcss.com has no custom setup, as nightwind should be able to handle it.
I would need some more details to understand the issue. Is it just the background transition not working? Is the actual inversion of colors working as expected? Feel free to also share some code snippets or images
Also please note that transitions won't work with gradients, and that you shouldn't apply color classes to the html element but only to the body element or lower

@jjranalli All other things transition perfectly, it's just the page background color that changes instantly. I haven't added any styles related to the background either. It might be worth noting that the page background for the demo site at https://night-tailwindcss.vercel.app/ also changes instantly as well. I'll try to upload a repo that can repro this sometime tomorrow.

Hey @jjranalli, I've uploaded a repo to reproduce this issue at https://github.com/kotx/tsuki. The files of interest are probably just https://github.com/kotx/tsuki/blob/master/src/pages/_app.tsx, https://github.com/kotx/tsuki/blob/master/tailwind.config.js, https://github.com/kotx/tsuki/blob/master/postcss.config.js, and https://github.com/kotx/tsuki/blob/master/src/styles/global.scss.

Thanks for providing the repo. Had a quick look, you're probably just missing @apply bg-white in the body styling in styles/global.css (like the comment, but you don't need to add dark:bg-black)
If you don't specify a starting color, nightwind has nothing to switch from/to
Let me know if that solves your issue, otherwise I'll give it a proper look tomorrow!

@jjranalli That works, thanks so much for the help. I don't know why I commented that line out haha.
Would this be worth adding in the README?

Glad that solved it! I don't think this should be added in the readme as it is an expected behaviour. However, since this has happened already in the past, I added a label in the issue so that it can be more easily found.
In the meantime I'll go ahead and close this


[FABB-148, FABB-149]

Added HSM updates for AWS HSM support
New bccsp parameters:

'Immutable`
'AltId` (required for AWS HSM)

And considerations around using them.
Signed-off-by: pama-ibm<EMAIL_ADDRESS>Type of change

Documentation update

Description

@ashku

For AWS HSM, I thought I heard a proxy was also required to be configured.

@denyeart Thanks for all the comments!
Given the time constraint here - would it be reasonable to address all the issues not related to FABB-148 and FABB-149 via a separate PR? Also, so they can get appropriately addressed in both the v1.4 and 2.x branches.

@denyeart Thanks for all the comments!
Given the time constraint here - would it be reasonable to address all the issues not related to FABB-148 and FABB-149 via a separate PR? Also, so they can get appropriately addressed in both the v1.4 and 2.x branches.

Yes, I'm ok with all the comments being addressed in subsequent PR. Therefore I'll approve with that understanding...

I opened this jira to address the remaining comments https://jira.hyperledger.org/browse/FAB-17732


Allow setting a priority on resolved Pushover notifications

Describe the feature request
It would be nice if I could set a separate priority for when alerts are resolved using Pushover.
Ideally I want alerts when triggered to be 1 (which is possible now) and when resolved 0 (not currently possible).
This is how Prometheus and Alertmanager currently operate for pushover for me:
priority: '{{ if eq .Status "firing" }}1{{ else }}0{{ end }}'

I would be over the moon if gatus could do something like that too.
Why do you personally want this feature to be implemented?
This would help cut down on alerting fatigue since some people might only be interested in getting alerted on problems at a higher priority and alerted on a lower priority when resolved.
How long have you been using this project?
18 months
Additional information
No response

@TwiN I would like to try and implement this but I am curious if you would be fine with the following config? The way alerting.pushover.priority-on-resolved would work is that it wouldn't be a breaking change to those using pushover already.
Configuring Pushover alerts

Parameter
Description
Default

alerting.pushover
Configuration for alerts of type pushover
{}

alerting.pushover.application-token
Pushover application token
""

alerting.pushover.user-key
User or group key
""

alerting.pushover.title
Fixed title for all messages sent via Pushover
Name of your App in Pushover

alerting.pushover.priority
Priority of all messages, ranging from -2 (very low) to 2 (emergency)
0

alerting.pushover.priority-on-resolved
Priority of message on resolved, ranging from -2 (very low) to 2 (emergency)
alerting.pushover.priority

alerting.pushover.sound
Sound of all messagesSee sounds for all valid choices.
""

alerting.pushover.default-alert
Default alert configuration. See Setting a default alert
N/A

I am glad I Googled and found this question, I also would like this very much.
It seems there isn't a PR for it. @onedr0p care to create a PR for it?
Otherwise I could give a go at writing go

Hi @Marck feel free to give it a try, I was waiting on feedback from @TwiN to go ahead but I probably won't have time to circle back on this for another few months.

@onedr0p I completely missed the notification!
Yeah, your suggestion looks perfect to me.
@Marck Feel free to ping me if you have any questions!

To keep things simple we could default the new option (alerting.pushover.priority-on-resolved) to 0, this also wouldn't break existing setups, people would need to adjust the value anyways.


Feature: compress/shorten mitosis fiddle URLs

It would be amazing if we can add some URL shortening capability to our https://mitosis.builder.io/ links. Right now, we just append a code query param containing the entire code block, which makes it really rough to share those links.
Any approach to compress the query param would be great

I searched string compression libraries and I found lz-string. You can find the draft implementation below. Implementation works but I don't have much idea about the string compression and I don't know if it's the best approach.
#578


How to hide the plus icon in left ?

Figured it out, Just Added color of Color.TRANSPARENT to it.

How can you set color to it if you are using it through gradle dependency?


Combine nargs == 1 with nargs < 1

The rank = 1 code path is just a loop unrolling of the general code path. That's not useful, lets not do it.
Also replaces 0 with S(0), and makes nargs == 0 work for the heck of it by using the initial argument to reduce.
First commit is #337, let's get that in first before merging this, so we can see if the lines this touches are covered.

The diff coverage is 0%.

Hmm, that's not reassuring. Probably best not to merge this until that file has some coverage.

Coverage drop is to be expected because this removes lines of code. Patch coverage is still high.


change source list of ubuntu

hi,  @sameersbn :
I want to change the source list of ubuntu repository,Shall I do it using your Ubuntu image?

Thanks.

Hi @fevxie. Sorry for the lateness of my response.
In general the sources.list file should be updated in your own Dockerfile. For an example take a look at https://github.com/sameersbn/docker-bind/blob/master/Dockerfile#L11.
Closing the issue, please re-open if you need further assitance


Data no longer automatically refreshed when calling EvohomeClient.temperatures()

Sorry this may be a deliberate change and not a bug, but in the previous release (0.2.8) a call to EvohomeClient.temperatures() would result in the status data being refreshed due to line 73 of controlsystem.py
status = self.location.status()
But in the latest version (0.3.1) that status call doesn't exist.
Is the intention now that the user has to manually request that the status data is refreshed?

Thanks for the report - I don't believe this was intentional (or at least I don't recall a discussion about it). It looks like in this commit (https://github.com/watchforstock/evohome-client/commit/f57fd55020a7bdb6a409a60f6b91025ea82dbb9b#diff-91be0e17c72f324a8437009c3c5c42bb) @zxdavb commented it out and presumably it was then subsequently removed. David, any view as to whether there was a reason behind this change?

@watchforstock I am sorry!
I think I was testing an idea, and then deleted the line, rather than remove the #.

TBH, the amount of refactoring that went on, we're lucky the bloody thing hasn't exploded!

@zxdavb Indeed! Thanks for the PR. @tmacecode This should now be fixed in master, but isn't yet in a released version.

That is great, thank you.
How often do you cut a new release?
From: Andrew Stock<EMAIL_ADDRESS>Sent: 18 March 2019 00:52
To: watchforstock/evohome-client
Cc: tmacecode; Mention
Subject: Re: [watchforstock/evohome-client] Data no longer automatically refreshed when calling EvohomeClient.temperatures() (#89)
@zxdavb https://github.com/zxdavb  Indeed! Thanks for the PR. @tmacecode https://github.com/tmacecode  This should now be fixed in master, but isn't yet in a released version.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/watchforstock/evohome-client/issues/89#issuecomment-473733931 , or mute the thread https://github.com/notifications/unsubscribe-auth/AtCbFiqVcnglxMFqYMZPIeVqWZki31obks5vXuMWgaJpZM4b3JZp .  https://github.com/notifications/beacon/AtCbFhrHeUHGfJSGXfr2vRjBdjk9mhIIks5vXuMWgaJpZM4b3JZp.gif

@tmacecode v0.3.2 is now available on pypi with this change in it...


Add the ability to specify --with-registry-auth when creating a service

Add the ability to support the equivalent of the --with-registry-auth flag when creating a service.
Reference: https://docs.docker.com/engine/reference/commandline/service_create/#options

I'm keen for this to but I'm wondering how it will actually work.
It's my understanding that --with-registry-auth simply forwards the credentials stored on the client running the service create or service update command to the node that will schedule the container and, given this, I can't see how portainer can/will implement it for cases where the registry uses one-time auth tokens, or time-expiring passwords (e.g. Amazon ECR).
Is the plan to add support for docker-credential-helper binaries or something similar?

IMO we should support secured registries first before looking into this.

I believe that this problem was solved with the support of private registries. Feel free to re-open if you have any troubles.


On Coral Dev Board, pose_camera.py and anonymizer.py quit before starting, and without warning

Both refuse to run.  They get through a few lines of setup and then exit.
The last line is "loading model..."
and then it just quits.
Running on Coral Dev Board, and I made the change you recommended to make it display the video in the gui.

Last line:
Loading model: models/mobilenet/posenet_mobilenet_v1_075_481_641_quant_decoder_edgetpu.tflite

Hello?

I used the coral camera instead of a usb webcam, it works now.


HDDS-5249. Race Condition between Full and Incremental Container Reports

What changes were proposed in this pull request?
During testing we came across an issue with ICR and FCR handing.
The following log shows the issue:
2021-05-18 13:14:15,394 DEBUG org.apache.hadoop.hdds.scm.container.ContainerReportHandler: Processing replica of container #1 from datanode 945aa180-5cff-4298-a8ad-8197542e4562{ip: <IP_ADDRESS>, host: quasar-nqdywv-7.quasar-nqdywv.root.hwx.site, ports: [REPLICATION=9886, RATIS=9858, RATIS_ADMIN=9857, RATIS_SERVER=9856, STANDALONE=9859], networkLocation: /default, certSerialId: null, persistedOpState: IN_SERVICE, persistedOpStateExpiryEpochSec: 0}

2021-05-18 13:14:15,394 DEBUG org.apache.hadoop.hdds.scm.container.IncrementalContainerReportHandler: Processing replica of container #1001 from datanode 945aa180-5cff-4298-a8ad-8197542e4562{ip: <IP_ADDRESS>, host: quasar-nqdywv-7.quasar-nqdywv.root.hwx.site, ports: [REPLICATION=9886, RATIS=9858, RATIS_ADMIN=9857, RATIS_SERVER=9856, STANDALONE=9859], networkLocation: /default, certSerialId: null, persistedOpState: IN_SERVICE, persistedOpStateExpiryEpochSec: 0}

2021-05-18 13:14:15,394 DEBUG org.apache.hadoop.hdds.scm.container.ContainerReportHandler: Processing replica of container #2 from datanode 945aa180-5cff-4298-a8ad-8197542e4562{ip: <IP_ADDRESS>, host: quasar-nqdywv-7.quasar-nqdywv.root.hwx.site, ports: [REPLICATION=9886, RATIS=9858, RATIS_ADMIN=9857, RATIS_SERVER=9856, STANDALONE=9859], networkLocation: /default, certSerialId: null, persistedOpState: IN_SERVICE, persistedOpStateExpiryEpochSec: 0}
2021-05-18 13:14:15,394 DEBUG org.apache.hadoop.hdds.scm.container.ContainerReportHandler: Processing replica of container #3 from datanode 945aa180-5cff-4298-a8ad-8197542e4562{ip: <IP_ADDRESS>, host: quasar-nqdywv-7.quasar-nqdywv.root.hwx.site, ports: [REPLICATION=9886, RATIS=9858, RATIS_ADMIN=9857, RATIS_SERVER=9856, STANDALONE=9859], networkLocation: /default, certSerialId: null, persistedOpState: IN_SERVICE, persistedOpStateExpiryEpochSec: 0}
2021-05-18 13:14:15,394 DEBUG org.apache.hadoop.hdds.scm.container.ContainerReportHandler: Processing replica of container #4 from datanode 945aa180-5cff-4298-a8ad-8197542e4562{ip: <IP_ADDRESS>, host: quasar-nqdywv-7.quasar-nqdywv.root.hwx.site, ports: [REPLICATION=9886, RATIS=9858, RATIS_ADMIN=9857, RATIS_SERVER=9856, STANDALONE=9859], networkLocation: /default, certSerialId: null, persistedOpState: IN_SERVICE, persistedOpStateExpiryEpochSec: 0}
...

In the above log, SCM is processing both an ICR and FCR for the same Datanode at the same time. The FCR does not container container #1001.
The FCR starts first, and it takes a snapshot of the containers on the node via NodeManager.
Then it starts processing the containers one by one.
The ICR then starts, and it added #1001 to the ContainerManager and to the NodeManager.
When the FCR completes, it replaces the list of containers in NodeManager with those in the FCR.
At this point, container #1001 is in the ContainerManager, but it is not listed against the node in NodeManager.
This would get fixed by the next FCR, but then the node goes dead. The dead node handler runs and uses the list of containers in NodeManager to remove all containers for the node. As #1001 is not listed, it is not removed by the DeadNodeManager. This means the container will never been seen as under replicated, as 3 copies will exist forever in the ContainerManager.
This issue is quite tricky to fully fix. There are two issues:

Parallel processing of ICR and FCR can lead to data inconsistency between the ComtainerManager and NodeManager. This is what caused the bug above.

A FCR wiping out a reference to a container recently sent in an ICR, but which is not included in the FCR.

The second issue is less serious, as the next FCR will fix the problem, as the FCRs are produced approximately every 60 seconds by default.
We can fix problem 1 quite easily by synchronising on the datanode when processing FCRs and ICRs, that will ensure the data inconsistency will not happen.
This PR is for issue 1, and we should probably create a followup issue for 2.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-5249
How was this patch tested?
Added a new test to reproduce the race condition and verified it passes after the code change.

cc @GlenGeng

+1. Thanks for the fix of this subtle issue.
BTW, about the issue 2,

A FCR wiping out a reference to a container recently sent in an ICR, but which is not included in the FCR.

Right now the order of FCR and ICR is not guaranteed, we may add some monotonically increasing
sequence number in datanode side so that SCM can figure out a stale FCR report and drop it.

@GlenGeng Thanks for the review. I will go ahead and commit this one, and raise a new Jira for issue 2.
I think you are correct, in that we may need a monotonically increasing sequence number in the datanode, plus maybe some locking in the DN to guarantee the contents of the FCR.
The hard part, is figuring out what to do with that information on SCM. I wonder if we need to attach the "report sequence number" to every replica in SCM. Then we can say:

The FCR is has sequence 100, and it does not have container 1001.
1001 is in SCM, but added by ICR sequence 101.
Right now, the FCR processing would remove container 1001, but with the sequence we could ensure it does not remove anything created by a newer sequence number.

However this approach adds a new field to every replica which would have a memory overhead, so we need to try to think of a better way.

HDDS-5267 raised to track / fix the second issue mentioned here.


Light not adapting

Home Assistant Adaptive Lighting Issue Template
Please confirm that you have completed the following steps:

[X] I have updated to the latest Adaptive Lighting version available in HACS.
[X] I have reviewed the Troubleshooting Section in the README.
[X] (If using Zigbee2MQTT) I have read the Zigbee2MQTT troubleshooting guide in the README.
[X] I have checked the V2 Roadmap and open issues to ensure my issue isn't a duplicate.

Required information for bug reports:
Please include the following information in your issue.
Issues missing this information may not be addressed.

Debug logs captured while the issue occurred. See here for instructions on enabling debug logging:

2024-06-19 22:08:03.946 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'light.toggle('['light.upstairs_bathroom_light']')' event with context.id='01J0SSV5FA1YAX39ZJQDHJD0T6'
2024-06-19 22:08:03.947 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (0) _service_interceptor_turn_on_handler: call.context.id='01J0SSV5FA1YAX39ZJQDHJD0T6', is_skipped_hash='False'
2024-06-19 22:08:03.947 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (1) _service_interceptor_turn_on_handler: call='<ServiceCall light.toggle (c:01J0SSV5FA1YAX39ZJQDHJD0T6): entity_id=['light.upstairs_bathroom_light'], params=>', service_data='{'entity_id': ['light.upstairs_bathroom_light'], 'params': {}}'
2024-06-19 22:08:03.947 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Switch is off or light is already on for entity_id='light.upstairs_bathroom_light', skipped='[]' (is_on='False', is_state='True', manual_control='False', switch._intercept='True')
2024-06-19 22:08:03.947 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (2) _service_interceptor_turn_on_handler: switch_to_eids='{}', skipped='['light.upstairs_bathroom_light']'
2024-06-19 22:08:04.103 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'on' → 'off' event for 'light.upstairs_bathroom_light' with context.id='01J0SSV5FA1YAX39ZJQDHJD0T6'

2024-06-19 22:08:07.501 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'light.toggle('['light.upstairs_bathroom_light']')' event with context.id='01J0SSV8YCQPYZFV3RDKSHWWK7'
2024-06-19 22:08:07.501 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (0) _service_interceptor_turn_on_handler: call.context.id='01J0SSV8YCQPYZFV3RDKSHWWK7', is_skipped_hash='False'
2024-06-19 22:08:07.501 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (1) _service_interceptor_turn_on_handler: call='<ServiceCall light.toggle (c:01J0SSV8YCQPYZFV3RDKSHWWK7): entity_id=['light.upstairs_bathroom_light'], params=>', service_data='{'entity_id': ['light.upstairs_bathroom_light'], 'params': {}}'
2024-06-19 22:08:07.502 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Switch is off or light is already on for entity_id='light.upstairs_bathroom_light', skipped='[]' (is_on='False', is_state='False', manual_control='False', switch._intercept='True')
2024-06-19 22:08:07.502 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (2) _service_interceptor_turn_on_handler: switch_to_eids='{}', skipped='['light.upstairs_bathroom_light']'
2024-06-19 22:08:07.657 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected a 'light.upstairs_bathroom_light' 'state_changed' event: '{'supported_color_modes': [<ColorMode.BRIGHTNESS: 'brightness'>], 'color_mode': None, 'brightness': None, 'icon': 'mdi:ceiling-light', 'friendly_name': 'Upstairs Bathroom Light', 'supported_features': <LightEntityFeature.TRANSITION: 32>}' with context.id='01J0SSV8YCQPYZFV3RDKSHWWK7'
2024-06-19 22:08:07.657 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'off' → 'on' event for 'light.upstairs_bathroom_light' with context.id='01J0SSV8YCQPYZFV3RDKSHWWK7'
2024-06-19 22:08:07.658 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] is_proactively_adapting_context='False', context_id='01J0SSV8YCQPYZFV3RDKSHWWK7'
2024-06-19 22:08:07.658 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] just_turned_off: State change 'off' → 'on' triggered by 'light.turn_on'

Your Adaptive Lighting configuration:

configed in UI I don't see a way to copy that here.  Mainly defaults, but also tried alot of options
adapt only once = off
adapt_only_on_bare_turn_on= off
separate_turn_on_commands = off
skip_redundant_commands = off
intercept = on
multi_light_intercept = off
include_config_in_attributes = off

(If using Zigbee2MQTT), provide your configuration files (remove all personal information before posting):
Zwave Inovelli switch

Describe the bug and how to reproduce it:

The light does not adapt at all

Steps to reproduce the behavior:
Turn light on - no adaption

3. (If using Zigbee2MQTT), provide your configuration files (remove all personal information before posting):
Zwave Inovelli switch

Which model is your Inovelli light dimmer?
Upon reviewing your debug logs, I am puzzled by this...
2024-06-19 22:08:03.947 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Switch is off or light is already on for entity_id='light.upstairs_bathroom_light', skipped='[]' (is_on='False', is_state='True', manual_control='False', switch._intercept='True')
2024-06-19 22:08:03.947 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (2) _service_interceptor_turn_on_handler: switch_to_eids='{}', skipped='['light.upstairs_bathroom_light']'
2024-06-19 22:08:04.103 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'on' → 'off' event for 'light.upstairs_bathroom_light' with context.id='01J0SSV5FA1YAX39ZJQDHJD0T6'
and
2024-06-19 22:08:07.502 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Switch is off or light is already on for entity_id='light.upstairs_bathroom_light', skipped='[]' (is_on='False', is_state='False', manual_control='False', switch._intercept='True')
2024-06-19 22:08:07.502 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (2) _service_interceptor_turn_on_handler: switch_to_eids='{}', skipped='['light.upstairs_bathroom_light']'
2024-06-19 22:08:07.657 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected a 'light.upstairs_bathroom_light' 'state_changed' event: '{'supported_color_modes': [<ColorMode.BRIGHTNESS: 'brightness'>], 'color_mode': None, 'brightness': None, 'icon': 'mdi:ceiling-light', 'friendly_name': 'Upstairs Bathroom Light', 'supported_features': <LightEntityFeature.TRANSITION: 32>}' with context.id='01J0SSV8YCQPYZFV3RDKSHWWK7'
2024-06-19 22:08:07.657 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'off' → 'on' event for 'light.upstairs_bathroom_light' with context.id='01J0SSV8YCQPYZFV3RDKSHWWK7'
This is my first time reviewing AL's debug logs but those two _Switch is off's (one for the on->off and the 2nd for the off->on) are making me wonder if your Adaptive Lighting and Adaptive Lighting Adapt Brightness switches are on?

This would be a LZW31-SN from Inovelli with firmware 1.57.

I can't tell if this is an Adaptive Lighting problem or the result of the Color Mixer Integration. But I am experiencing the same problem. Here's my debug output for AL. Of note is the error No switch found for entity_id='light.ensuite_vanity_led_lights' which doesn't make any sense to me. The light.ensuite_vanity_led_lights definitely has a "switch" and I can toggle it on and off and change the color/temp using the normal HA way in the UI and the service calls. But AL seems to be having problems?
2024-07-11 12:11:02.128 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] No switch found for entity_id='light.ensuite_vanity_led_lights', skipped='['light.ensuite_vanity_led_lights']'
2024-07-11 12:11:02.128 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (2) _service_interceptor_turn_on_handler: switch_to_eids='{}', skipped='['light.ensuite_vanity_led_lights']'
2024-07-11 12:11:02.128 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'light.turn_on('['light.ensuite_vanity_led_lights_channel_2']')' event with context.id='01J2FRXTVFVBKVJGAHRVTMJTHJ'
2024-07-11 12:11:02.129 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (0) _service_interceptor_turn_on_handler: call.context.id='01J2FRXTVFVBKVJGAHRVTMJTHJ', is_skipped_hash='False'
2024-07-11 12:11:02.129 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (1) _service_interceptor_turn_on_handler: call='<ServiceCall light.turn_on (c:01J2FRXTVFVBKVJGAHRVTMJTHJ): entity_id=['light.ensuite_vanity_led_lights_channel_2'], params=brightness=128>', service_data='{'entity_id': ['light.ensuite_vanity_led_lights_channel_2'], 'params': {'brightness': 128}}'
2024-07-11 12:11:02.129 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] No switch found for entity_id='light.ensuite_vanity_led_lights_channel_2', skipped='['light.ensuite_vanity_led_lights_channel_2']'
2024-07-11 12:11:02.129 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (2) _service_interceptor_turn_on_handler: switch_to_eids='{}', skipped='['light.ensuite_vanity_led_lights_channel_2']'
2024-07-11 12:11:02.131 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'light.turn_on('['light.ensuite_vanity_led_lights_channel_1']')' event with context.id='01J2FRXTVFVBKVJGAHRVTMJTHJ'
2024-07-11 12:11:02.131 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (0) _service_interceptor_turn_on_handler: call.context.id='01J2FRXTVFVBKVJGAHRVTMJTHJ', is_skipped_hash='False'
2024-07-11 12:11:02.131 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (1) _service_interceptor_turn_on_handler: call='<ServiceCall light.turn_on (c:01J2FRXTVFVBKVJGAHRVTMJTHJ): entity_id=['light.ensuite_vanity_led_lights_channel_1'], params=brightness=0>', service_data='{'entity_id': ['light.ensuite_vanity_led_lights_channel_1'], 'params': {'brightness': 0}}'
2024-07-11 12:11:02.132 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] No switch found for entity_id='light.ensuite_vanity_led_lights_channel_1', skipped='['light.ensuite_vanity_led_lights_channel_1']'
2024-07-11 12:11:02.132 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] (2) _service_interceptor_turn_on_handler: switch_to_eids='{}', skipped='['light.ensuite_vanity_led_lights_channel_1']'
2024-07-11 12:11:02.230 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected a 'light.ensuite_vanity_led_lights_channel_2' 'state_changed' event: '{'supported_color_modes': [<ColorMode.BRIGHTNESS: 'brightness'>], 'color_mode': <ColorMode.BRIGHTNESS: 'brightness'>, 'brightness': 128, 'friendly_name': 'Ensuite Vanity LED Lights channel 2', 'supported_features': <LightEntityFeature.TRANSITION: 32>}' with context.id='01J2FRXTVFVBKVJGAHRVTMJTHJ'
2024-07-11 12:11:02.231 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected an 'off' → 'on' event for 'light.ensuite_vanity_led_lights_channel_2' with context.id='01J2FRXTVFVBKVJGAHRVTMJTHJ'
2024-07-11 12:11:02.231 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] is_proactively_adapting_context='False', context_id='01J2FRXTVFVBKVJGAHRVTMJTHJ'
2024-07-11 12:11:02.231 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] just_turned_off: State change 'off' → 'on' triggered by 'light.turn_on'

I'm having the same issue - my lights aren't adapting, and I'm using the Color Mixer Integration same as @lennon101. I noted in my logs I had the following:
2024-08-07 20:57:41.782 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected a 'light.kitchen_island_led_strips_cool' 'state_changed' event: '{'supported_color_modes': [<ColorMode.BRIGHTNESS: 'brightness'>], 'color_mode': <ColorMode.BRIGHTNESS: 'brightness'>, 'brightness': 13, 'friendly_name': 'Kitchen Island LED Strip Cool', 'supported_features': <LightEntityFeature.TRANSITION: 32>}' with context.id='01J4P7SJTZ:al:JNUX:0slp:03' 2024-08-07 20:57:41.782 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] AdaptiveLightingManager: New adapt '<state light.kitchen_island_led_strips_cool=on; supported_color_modes=[<ColorMode.BRIGHTNESS: 'brightness'>], color_mode=brightness, brightness=13, friendly_name=Kitchen Island LED Strip Cool, supported_features=32 @ 2024-08-07T20:08:14.734791+10:00>' found for light.kitchen_island_led_strips_cool 2024-08-07 20:57:41.782 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Start transition timer of 1.0 seconds for light light.kitchen_island_led_strips_cool 2024-08-07 20:57:41.811 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Detected a 'light.kitchen_island_strips_warm' 'state_changed' event: '{'supported_color_modes': [<ColorMode.BRIGHTNESS: 'brightness'>], 'color_mode': <ColorMode.BRIGHTNESS: 'brightness'>, 'brightness': 13, 'friendly_name': 'Kitchen Island LED Strip Warm', 'supported_features': <LightEntityFeature.TRANSITION: 32>}' with context.id='01J4P7SJTZ:al:JNUX:0slp:03' 2024-08-07 20:57:41.812 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] AdaptiveLightingManager: New adapt '<state light.kitchen_island_strips_warm=on; supported_color_modes=[<ColorMode.BRIGHTNESS: 'brightness'>], color_mode=brightness, brightness=13, friendly_name=Kitchen Island LED Strip Warm, supported_features=32 @ 2024-08-07T20:08:14.736337+10:00>' found for light.kitchen_island_strips_warm
2024-08-07 20:57:42.784 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.kitchen_island_led_strips_cool 2024-08-07 20:57:42.813 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.kitchen_island_strips_warm 2024-08-07 20:57:42.827 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.pantry_led_strips_right_cool 2024-08-07 20:57:42.855 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.pantry_led_strips_right_warm 2024-08-07 20:57:42.910 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.kitchen_led_strip_main_cool 2024-08-07 20:57:42.934 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.kitchen_led_strip_main_warm 2024-08-07 20:57:42.950 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.pantry_led_strip_left_cool 2024-08-07 20:57:42.971 DEBUG (MainThread) [custom_components.adaptive_lighting.switch] Transition finished for light light.pantry_led_strip_left_warm
This is a bit bizarre, as I don't specifically select those entities. I have the Color Mixer Integration entities selected instead:

I'm guessing that the two integrations are messing with each other in some way. I'm assuming that Adaptive Lighting should not be interacting directly with the individual channels, rather just the aggregated 'light group' (for want of a better term) provided by the Color Mixer Integration. Not sure if this helps narrow things down or just adds to the noise!


How to get osdslet working with keystone

Describe the bug
The osdslet service works fine with noauth.   How do I get keystone working?
E0214 15:57:27.037359   24025 keystone.go:60] When get auth client:Authentication failed
To Reproduce
[osdslet]
api_endpoint = <IP_ADDRESS>:50040
graceful = True
socket_order = inc
log_file = /var/log/opensds/osdslet.log
auth_strategy = keystone

Expected behavior
I would like osdslet to authenticate with keystone.
Screenshots
My devstack installation appears to work fine.
root@ubuntu-bionic:/var/log/opensds# su - stack
stack@ubuntu-bionic:~$ source ~/openrc admin admin && openstack group list
WARNING: setting legacy OS_TENANT_NAME to support cli tools.
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 02fc59a62f3b45a9b02bc3471d7dc4cf | admins  |
| 49c2190817e44ef49a6826715434ac8f | service |
+----------------------------------+---------+

stack@ubuntu-bionic:~$ source ~/openrc admin admin && openstack user list
WARNING: setting legacy OS_TENANT_NAME to support cli tools.
+----------------------------------+-------------------+
| ID                               | Name              |
+----------------------------------+-------------------+
| 37ca03f865cb495e8a23c34bd82422dd | opensdsv0.4.0     |
| 5dfe39982ec8430ca51e966d930dc81b | multi-cloudv0.5.0 |
| 93f1472b4fd345b3b5a9a706dfb4e454 | noel              |
| bef45e3bf05444e8b611f7577092cce4 | admin             |

For troubleshooting I tried passing environment variables to systemd - but osdslet uses /etc/opensds/opensds.conf not environment.  How do I make osdslet work with keystone?
[Service]
WorkingDirectory=/usr/local/golang/packages/src/github.com/opensds//opensds//build/out/bin
Environment='OPENSDS_ENDPOINT=<IP_ADDRESS>:50040'
Environment='CSI_ENDPOINT=<IP_ADDRESS>:50051'
Environment='OPENSDS_AUTH_STRATEGY=keystone'
Environment='OS_PROJECT_NAME=service'
Environment='OS_USERNAME=opensds'
Environment='OS_PASSWORD=opensds@123'
Environment='ADMIN_PASSWORD=opensds@123'
ExecStart=/usr/local/bin/osdslet
ExecStop=/usr/bin/killall osdslet

Additional context
Add any other context about the problem here.

@xxwjj, Jerry could you take a look at this issue? thanks!

Hi @noelmcloughlin, any update on this issue?

Hey @leonwanghui I have no update. The osdslet service reads configuration from opensds.conf and cannot start when auth_strategy: keystone even if devstack-keystone was installed.
E0214 15:57:27.037359 24025 keystone.go:60] When get auth client:Authentication failed

Hi @noelmcloughlin, now ansible has been supported containerized keystone deployment, please update salt to support it, thanks!

Agreed - I will add this feature when I get time.  I'm not sure it fixes the issue - maybe osdslet needs some variables exported to its runtime environment.  Was #142 was tested successfully with osdslet daemon and dashboard.

@noelmcloughlin , can we close this issue or any update?

I will close this for now. Soon I will be working on updating salt installer with ansible installer features.


Added an option to disable the Date Text and update the README

Added an option to disable the TextInput (hideText), added it to the README and fixed the README array

Coverage remained the same at 95.276% when pulling 86085312b37cb359196fe60174367766d14764fb on avencat:hideDateText into 2e63d0b086d411fd81670d78aefc4fba113d6fcc on xgfe:master.

Thanks very much! But you can hide the text with style. Can your update the readme with another issue and using markdown only? Or I'll fix by myself.

Hi @feyy ! I've had some issue when trying to hide the icon with style only where the border stayed ! ;) So I managed to do this, it was the only way for me to disable the dateText... (I also followed #117)

Coverage remained the same at 95.313% when pulling 0b208858d6ae3ca0126be953c3f204a286b5ddde on avencat:hideDateText into 617b674c07e9e1835b4f86a66628a8f560bcf84a on xgfe:master.

@feyy Here what I get with:
customStyles={{
  dateInput: {
    borderStyle: null,
    height: 0,
    width: 0,
  }
}}

(I still get the little dot at the left)
But with this PR, as the textInput won't render anymore, I will be able to delete this little dot.
Is this possible to merge it ?

Hi! I've upgraded to react-native v0.45 and it seems that you can't hide the text with style anymore. Can you confirm that?
I get this:

with this style:
dateInput: {
  borderWidth: 0,
  borderStyle: null,
  height: 0,
  width: 0,
},

@feyy I've tested this PR on RN v0.45 and it works well. Could you merge this please ?