Native Keycloak SSO ValueError

Bug description
Upon configuring the Keycloak client and the DefectDojo helm chart as described in the doc, SSO is not working. Pressing the Login With Keycloak button redirects me to a Server Error (500)
Keycloak client configuration:

Client Settings:

Client ID: defectdojo
Enabled: True
Client Protocol: openid-connect
Access Type: confidential
Root URL: https://{ defectdojo url }
Valid Redirect URIs:

https://{ defectdojo url }/*

Admin URL: https://{ defectdojo url }
Web Origins: https://{ defectdojo url }/*
Backchannel Logout Session Required: True

Client Settings -> Fine Grain OpenID Connect Configuration

User Info Signed Response Algorithm: RS256
Request Object Signature Algorithm: RS256

Scope -> Full Scope Allowed: False
Mappers:

Name: aud
Mapper type: Audience
Included audience: defectdojo
Add ID to token: off
Add access to token: on

Expected behavior
Login via keycloak should ... well ... log me in
Deployment method (select with an X)

[ ] Docker Compose
[x] Kubernetes
[ ] GoDojo

Environment information

Operating System: [e.g. Ubuntu 18.04]
DefectDojo version (see footer) or commit message: Chart 1.6.27

Logs
Traceback (most recent call last):
--
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/django/core/handlers/exception.py", line 47, in inner
Thu, Feb 3 2022 2:28:13 pm | response = get_response(request)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/django/core/handlers/base.py", line 181, in _get_response
Thu, Feb 3 2022 2:28:13 pm | response = wrapped_callback(request, *callback_args, **callback_kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/django/views/decorators/cache.py", line 44, in _wrapped_view_func
Thu, Feb 3 2022 2:28:13 pm | response = view_func(request, *args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
Thu, Feb 3 2022 2:28:13 pm | return view_func(*args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_django/utils.py", line 46, in wrapper
Thu, Feb 3 2022 2:28:13 pm | return func(request, backend, *args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_django/views.py", line 31, in complete
Thu, Feb 3 2022 2:28:13 pm | return do_complete(request.backend, _do_login, user=request.user,
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_core/actions.py", line 45, in do_complete
Thu, Feb 3 2022 2:28:13 pm | user = backend.complete(user=user, *args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_core/backends/base.py", line 40, in complete
Thu, Feb 3 2022 2:28:13 pm | return self.auth_complete(*args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_core/utils.py", line 247, in wrapper
Thu, Feb 3 2022 2:28:13 pm | return func(*args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_core/backends/oauth.py", line 391, in auth_complete
Thu, Feb 3 2022 2:28:13 pm | return self.do_auth(response['access_token'], response=response,
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_core/utils.py", line 247, in wrapper
Thu, Feb 3 2022 2:28:13 pm | return func(*args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_core/backends/oauth.py", line 397, in do_auth
Thu, Feb 3 2022 2:28:13 pm | data = self.user_data(access_token, *args, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/social_core/backends/keycloak.py", line 119, in user_data
Thu, Feb 3 2022 2:28:13 pm | return jwt.decode(
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/jwt/api_jwt.py", line 119, in decode
Thu, Feb 3 2022 2:28:13 pm | decoded = self.decode_complete(jwt, key, algorithms, options, **kwargs)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/jwt/api_jwt.py", line 90, in decode_complete
Thu, Feb 3 2022 2:28:13 pm | decoded = api_jws.decode_complete(
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/jwt/api_jws.py", line 152, in decode_complete
Thu, Feb 3 2022 2:28:13 pm | self._verify_signature(signing_input, header, signature, key, algorithms)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/jwt/api_jws.py", line 236, in _verify_signature
Thu, Feb 3 2022 2:28:13 pm | key = alg_obj.prepare_key(key)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/jwt/algorithms.py", line 264, in prepare_key
Thu, Feb 3 2022 2:28:13 pm | key = load_pem_public_key(key)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/cryptography/hazmat/primitives/serialization/base.py", line 30, in load_pem_public_key
Thu, Feb 3 2022 2:28:13 pm | return ossl.load_pem_public_key(data)
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 853, in load_pem_public_key
Thu, Feb 3 2022 2:28:13 pm | self._handle_key_loading_error()
Thu, Feb 3 2022 2:28:13 pm | File "/usr/local/lib/python3.8/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 1094, in _handle_key_loading_error
Thu, Feb 3 2022 2:28:13 pm | raise ValueError(
Thu, Feb 3 2022 2:28:13 pm | ValueError: Could not deserialize key data. The data may be in an incorrect format or it may be encrypted with an unsupported algorithm.

Sample scan files
If applicable, add sample scan files to help reproduce your problem.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context (optional)
Add any other context about the problem here.

From the trace it looks like public key loaded into env vars is wrong.
https://github.com/DefectDojo/django-DefectDojo/pull/5726#discussion_r782148096

Oh... silly mistake on my part. I updated the extraConfig and issues a helm upgrade, but the pods weren't restarted. Manually deleting them to force a restart solved my issue. Thanks

Anyway you can enable trackConfig in gel, then all dd containers will be restarted automatically on config change


Request for adding 2 Vulkan extensions: variable pointers, conservative rasterization..

Hi,
don't know if it's the correct place to ask for new Vulkan extensions to be supported on AMD drivers like AMDVLK but anyway I will ask here:
first is VK_KHR_variable_pointers I ask because is needed by clspv tool for converting OpenCL kernels to Vulkan compute shaders and is supported almost everywhere (NV drviers, Intel ANV,Adreno) (even by AMD RADV driver):
http://vulkan.gpuinfo.org/listreports.php?extension=VK_KHR_variable_pointers
second is VK_EXT_conservative_rasterization a new ext. reléased last month..
supported right now by Nvidia dev driver and also seen this string on Intel HD Graphics Vulkan  Windows driver so seems support is coming soon for it..
it's a D3D12 optional feature so makes sense to expose also to Vulkan devs.. should be good to VKD3D project devs eventually (a D3D12 Vulkan wrapper)..

Thanks for the request. We added it into our TODO list

closing it.. these two are supported..


docker network inspect shows only the current node's container in case of overlay driver

Description of problem:
So when I create and overlay network driver and create two containers in that network  but on two different node and inspect the created network on one of the nodes I got only those containers which is on the same node on which I executed the inspect command.
It can be said it is expected, but I think in this case I would like to see all the containers in the network for example debugging purposes or else.
I think it is important both containers can ping each other. So it is just I don't know how should I call it just an ouput error, I think I am not sure in that.
docker version:
Client:
Version:      1.9.1
API version:  1.21
Go version:   go1.4.3
Git commit:   a34a1d5
Built:        Fri Nov 20 17:56:04 UTC 2015
OS/Arch:      linux/amd64
Server:
Version:      1.9.1
API version:  1.21
Go version:   go1.4.3
Git commit:   a34a1d5
Built:        Fri Nov 20 17:56:04 UTC 2015
OS/Arch:      linux/amd64
docker info:
Containers: 1
Images: 16
Server Version: 1.9.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 18
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.16.0-30-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 1
Total Memory: 993.7 MiB
Name: lmesz-node2
ID: 5MBM:ZF4N:BDID:M6AW:5R3P:6E5L:43GR:LTLO:BLKM:DFRW:UNVI:F42J
Debug mode (server): true
File Descriptors: 31
Goroutines: 71
System Time: 2015-11-23T13:07:37.273825687+01:00
EventsListeners: 1
Init SHA1:
Init Path: /usr/bin/docker
Docker Root Dir: /var/lib/docker
WARNING: No swap limit support
Cluster store: etcd://<IP_ADDRESS>:2379/dockerNetwork
Cluster advertise: <IP_ADDRESS>:22222
uname -a:
Linux lmesz-node2 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Environment details:
Both node are virtualbox virtual machine
Additional info:
I use etcd for backend.
Reproduction steps:

Start two docker daemon on different host. (/usr/bin/docker daemon -D -H unix:///var/run/docker.sock -H tcp://<IP_ADDRESS>:5454 --cluster-store=etcd://<IP_ADDRESS>:2379/dockerNetwork --cluster-advertise=eth0:2222)
Create and overlay network (docker network create -d overlay multi-host)
On node one run a simple container with exposed port (docker run -d -p 24240:24240 --net=multi-host --name almafa tutum/hello-world )
On node one run a simple container with exposed port (docker run -d -p 24241:24241 --net=multi-host --name kortefa tutum/hello-world )
On the node when you created the first container inspect the previously created network driver (docker network inspect multi-host)
Check the Containers part:

Actual result:
Result contains only those containers in the network which created on the current node.
Expected result:
inspect contains all the containers which are in the same network
Additional info:
Doh! I forget to mention in case of swarm the result is the same I see only those containers which are created on the node on which I executed the command.

/cc @aboch @mavenugo @mrjana

@lmesz @thaJeztah As of 1.9.x, docker engine manages only those containers that are local to self. Multi-host networking just provides connectivity between containers across hosts and doesn't necessarily means that docker engine manages containers across host. That's Swarm's responsibility & would be an appropriate issue in docker/swarm project.

@mavenugo thanks, and yes, I was thinking along that way; @lmesz can you reopen this issue in the https://github.com/docker/swarm repository?
I'll close the issue here

Hm... I think when I say "docker network inspect" I expect to see all the Network related containers. E.g.: what if I check if there is a container belongs to this network if the answer is no I destroy the Network. If without the Network the containers work properly then okay no need to show all the containers else I think it is necessary.
And okay I create in issue in swarm

Already exists: docker/swarm#1373

hello，i have problem ,i only use docker ,etcd, i create overlay is name ovr0 ,i docker run 3 containers on 2 hosts,i Immediately docker network inspect ovr0 ,the inspect contains theses containers,after time, i want to
inspect ovr0's containers.but no these containers .but 3 conntainers can ping ok. and ,after time,the multi_host contains can not ping ok ,the 1 host's 2 containers can ping ok. why?


Cannot find module @mui/icons-material in v0.16.26

It pertains to wallet-adapter-material-ui. I made a post about it on stackoverflow and I essentially had to stick with v0.16.22 to resolve the issue.
https://stackoverflow.com/questions/75504022/cannot-find-node-module-after-deleting-yarn-lock-package-lock-json?noredirect=1#comment133223432_75504022

Can confirm, same thing. Left a comment here on the possible cause: https://github.com/solana-labs/wallet-adapter/commit/54061676920bccfdcb350298b1cc070c38f92a87#r101354991

Can confirm, same thing
Might be related to this: https://github.com/solana-labs/wallet-adapter/pull/728/files#diff-0a9b3997ed030b2a1ffc834f3f7b54133507367ac0e15673c01c2b57ab21b10aR3-R11
or this: https://github.com/solana-labs/wallet-adapter/commit/54061676920bccfdcb350298b1cc070c38f92a87#r101354991

Thanks for this, those changes definitely look like they could be causing an issue here so I'd like to take a closer look at this. I'm having trouble reproducing it though, do you have an example repo by any chance?
Here's what I tried:

Create a new NextJS app with Typescript:

npx create-next-app --typescript wa-test

Install packages including material-ui:

npm install @solana/wallet-adapter-base @solana/wallet-adapter-react @solana/wallet-adapter-material-ui @solana/wallet-adapter-wallets

Verify the installed version is 0.16.26:

$ grep material-ui package-lock.json
        "@solana/wallet-adapter-material-ui": "^0.16.26",
    "node_modules/@solana/wallet-adapter-material-ui": {
      "resolved"<EMAIL_ADDRESS>    "@solana/wallet-adapter-material-ui": {
      "resolved"<EMAIL_ADDRESS>

Remove package-lock.json, run npm install again, verify the installed version is again 0.16.26 . This worked correctly for me

Remove package-lock.json, run yarn, verify the installed version in yarn.lock:

$ grep material-ui yarn.lock
"<EMAIL_ADDRESS>  resolved<EMAIL_ADDRESS>
So it looks like using both npm and yarn I can generate the lockfile with the 0.16.26 version without any issues.

@mcintyre94 I have my own repo which you can start. If it's too bothersome for you, I can strip it off and have you reproduce on a more bare bone version of it: https://github.com/d-reader-organization/d-reader-frontend

clone the repository and check into main
npm install
copy .env values as pasted below
npm run dev (no issues present)
npm install @solana/wallet-adapter-material-ui@latest (issues arise)
npm install<EMAIL_ADDRESS>(issues gone away)

NEXT_PUBLIC_API_ENDPOINT='https://api.dev.dreader.io'
NEXT_AWS_BUCKET_NAME=d-reader-dev
NODE_ENV='development'
PORT=3000

Thanks! I was mis-understanding where the error happens, I thought it was installing/generating lock files. I'm able to repro this on my test next app:

Missing dependencies: npm install @emotion/styled @emotion/react

Add import { WalletConnectButton } from "@solana/wallet-adapter-material-ui" + <WalletConnectButton /> to pages/index.tsx

I guess the next mystery is why our example app seems to work, and if that gives any clues for fixing it here. I noticed that it wasn't hardcoded to the latest version as I thought it was, but it continues to work if I change its dependency to ^0.16.26.

I have a hunch but can't express myself properly without a PC nearby. I'll look into this in a day or two if the issue persists.
Till then maybe (if this is even possible??) unpublish a faulty version to safe a few devs from headaches?

Prediction: this is 1000% going to come down to two mismatched versions of React existing.

Nope. https://github.com/mui/material-ui/issues/35233


chore(main): release 1.4.2

:robot: I have created a release beep boop
1.4.2 (2024-07-10)
Other

Upgrade to Pydantic v2 using TypeAdapters (#24) (74c3e04)
Use ruff formatter (#25) (c0ef09e)

CI/CD

Add build to "Other" section for release docs (#27) (865b752)
Fix release-please typo in config (#28) (fd2b51e)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/equinor/atmos-validation/releases/tag/v1.4.2 :sunflower:


esbuild: 0.12.0 -> 0.12.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/evanw/esbuild/releases.
meta.description for esbuild is: "An extremely fast JavaScript bundler"
meta.homepage for esbuild is: "https://esbuild.github.io"
meta.changelog for esbuild is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/sgxssnsa0snj1k3cq00gdj8ydbif1f2j-esbuild-0.12.1/bin/esbuild passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 0.12.1 with grep in /nix/store/sgxssnsa0snj1k3cq00gdj8ydbif1f2j-esbuild-0.12.1

found 0.12.1 in filename of file in /nix/store/sgxssnsa0snj1k3cq00gdj8ydbif1f2j-esbuild-0.12.1

directory tree listing: https://gist.github.com/fbd1fc91627bc7034d7f28bacdb94e74

du listing: https://gist.github.com/5853d49f831f6c5b1a81652d109cdc24

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

228 total rebuild path(s)

70 package rebuild(s)

70 x86_64-linux rebuild(s)
65 i686-linux rebuild(s)
28 x86_64-darwin rebuild(s)
65 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
alfred
avocode
batctl
betterlockscreen
cloudflared
deepspeech
elixir_ls
erlang-ls
esbuild
fcl
grafana
home-assistant
intel-media-driver
ipinfo
lfe
lfe_1_2
lfe_1_3
liblinphone
linphone
linuxPackages-libre.batman_adv
linuxPackages.batman_adv
linuxPackages_4_14.batman_adv
linuxPackages_4_19.batman_adv
linuxPackages_4_4.batman_adv
linuxPackages_4_9.batman_adv
linuxPackages_5_10.batman_adv
linuxPackages_5_11.batman_adv
linuxPackages_5_12.batman_adv
linuxPackages_5_4.batman_adv
linuxPackages_hardened.batman_adv
linuxPackages_hardkernel_4_14.batman_adv
linuxPackages_hardkernel_latest.batman_adv
linuxPackages_latest-libre.batman_adv
linuxPackages_latest.batman_adv
linuxPackages_latest_hardened.batman_adv
linuxPackages_lqx.batman_adv
linuxPackages_testing_bcachefs.batman_adv
linuxPackages_xanmod.batman_adv
linuxPackages_zen.batman_adv
matrix-appservice-irc
mediastreamer
mediastreamer-openh264
moc
msilbc
netlify-cli
nextcloud19
nextcloud20
nextcloud21
nixos-install-tools
octomap

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A esbuild https://github.com/r-ryantm/nixpkgs/archive/26fccabad0cafe45590d845c306ad01b6d6e45b7.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/sgxssnsa0snj1k3cq00gdj8ydbif1f2j-esbuild-0.12.1
ls -la /nix/store/sgxssnsa0snj1k3cq00gdj8ydbif1f2j-esbuild-0.12.1/bin

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

2 packages built:

esbuild
netlify-cli

Maintainer pings
cc @Lucus16 @kalbasit for testing.

Result of nixpkgs-review pr 123958 run on x86_64-darwin 1

1 package built:

esbuild

This is a very minor version update


Moved ci-jenkins-helper files to here for common library loading

https://github.com/adoptium/ci-jenkins-pipelines/issues/313


New version: pnpm.pnpm version 8.7.3

Pull request has been created with WinGet Releaser v2 :rocket:
Microsoft Reviewers: Open in CodeFlow

I think this version has a regression, so I am closing the PR.


crypto/tls: regression in Handshake behavior for bad certificates

Commit 37c28759ca46cf381a466e32168a793165d9c9e9 caused a regression in the tls package that causes some tests to fail.
This is my hypothesis (I'm not an expert in the TLS protocol):
Previously, in the event of a bad client certificate (using the ClientAuth feature), the server would inform the client that the client's certificate was rejected before returning from the Handshake method. After the change mentioned, it seems that Handshake would return before the client is informed of the failure.
Consider the following code (where the client is using a bad certificate and should fail the Handshake):
// Snippet of server-side logic.
if err := tc.(*tls.Conn).Handshake(); err != nil {
	// If the client presented a bad cert, it seems reasonable to
	// Close the connection immediately.
	tc.Close()
}

// Snippet of client-side logic.
if err := c.Handshake(); err != nil {
	// The client is intentionally using a bad certificate, so we expect that
	// the error be "bad certificate". However, it is more often a "pipe error" instead.
	panic(err)
}

If the server's Handshake returns before it informs the client of a bad certificate, then there is a race condition going on here. As the client's Handshake is asking the server for the status of the TLS handshake, the client's packet may be received by the server before the server calls tc.Close or it may be received after calling tc.Close. If received before, then the client's Handshake will properly return an "bad certificate" error. However, if received after, then the client's Handshake will return a "broken pipe" error, which is more indicative of a network failure, than an authentication error.
Putting a time.Sleep(time.Second) before calling tc.Close on the server makes the client's Handshake almost always return 'bad certificate', further indicating that this is a race.
See this example: https://play.golang.org/p/7aY0K9wcEW
@agl, @bradfitz

/cc @tamird also

I might as post these from my debugging yesterday. They are TCP dumps of the communication between client and server. stream_good is from running on go1.6, while stream_bad is from running 81a8960. In the files peer0 is the client and peer1 is the server.
steam_good.txt
stream_bad.txt

cc @agl

CC @tamird

Not sure what help I can provide here without a failing test. The change in 37c2875 only does better error handling, so whatever is happening here is the result of an unmasking of some other bug.

@tamird There is a failing test in the initial report.  The program wants to consistently see a "bad certificate" error.  Instead it sometimes sees a write error.
I don't think there is a hidden bug here.  What seems to be happening is that the server reads some data, detects a bad certificate, sends an alert, and closes the connection.  The client seems to write some data including a bad certificate, then write some more data.  The second write fails and the client reports a write error, rather than checking for the alert sent from the server.  I think.

OK, looking.

https://golang.org/cl/23604

https://go-review.googlesource.com/23609 is my take on this. It appears to solve the problem and also saves some packets on the wire.
I am not sure whether it's suitable for landing during the freeze, however.

@agl if this is a fix for a regression then it seems suitable to the release for me.
Getting it in before the beta means that it should be sufficiently tested before the final release.
How would you rate the risk of this change?

I think it has a low risk, but there's a fair amount of uncertainty in that. It's possible that some implementations may be sensitive to how the handshake is cut up into packets and that's very hard to predict.
If you're happy using the beta process to test it then I've no problem with it landing. (I'm not sure how to write a good test for it, however, because it's inherently about a race. I think counting the number of writes in a handshake might be the best solution.)

I'd be happy to include it in the beta and encourage testing by people doing interesting things with TLS.
If it were any later then I wouldn't accept it.


Script does not work

Hi, the script does not work for me. After running the script Synology can't boot the DSM package and Container Manager needs to be repaired. Fixed cidr was unchanged while I am using the fe80::1/64 as well. Thanks for help

What do the following 2 commands return?
cat "/var/packages/ContainerManager/etc/dockerd.json"
cat "/var/packages/ContainerManager/target/config/dockerd.json"

ianlockhead@Synology:/$ sudo jq . "/var/packages/ContainerManager/etc/dockerd.json" Password:  {   "data-root": "/var/packages/ContainerManager/var/docker",   "log-driver": "db",   "registry-mirrors": [],   "seccomp-profile": "unconfined",   "storage-driver": "btrfs" } ianlockhead@Synology:/$ sudo jq . "/var/packages/ContainerManager/target/config/dockerd.json" {   "registry-mirrors": [],   "data-root": "/var/packages/ContainerManager/var/docker",   "log-driver": "db",   "seccomp-profile": "unconfined"

ianlockhead@Synology:/$ sudo jq . "/var/packages/ContainerManager/etc/dockerd.json"
{
"data-root": "/var/packages/ContainerManager/var/docker",
"log-driver": "db",
"registry-mirrors": [],
"seccomp-profile": "unconfined",
"storage-driver": "btrfs"
}
ianlockhead@Synology:/$ sudo jq . "/var/packages/ContainerManager/target/config/dockerd.json"
{
"registry-mirrors": [],
"data-root": "/var/packages/ContainerManager/var/docker",
"log-driver": "db",
"seccomp-profile": "unconfined"

Was this after clicking on Repair in storage manager?
What do these commands return?
cat "/var/packages/ContainerManager/etc/dockerd.json" && echo
cat "/var/packages/ContainerManager/target/config/dockerd.json" && echo

Hi, yes both json files were restored manually from backup after repairing the syno package.
I can run the script again and paste the cat command output but it will brick the package again I think.
After backup restore the jsons looks:
ianlockhead@Synology:/$ sudo cat "/var/packages/ContainerManager/etc/dockerd.json" && echo
Password:
{"data-root":"/var/packages/ContainerManager/var/docker","log-driver":"db","registry-mirrors":[],"seccomp-profile":"unconfined","storage-driver":"btrfs"}
ianlockhead@Synology:/$ sudo cat "/var/packages/ContainerManager/target/config/dockerd.json" && echo
{
"registry-mirrors": [],
"data-root": "/var/packages/ContainerManager/var/docker",
"log-driver": "db",
"seccomp-profile": "unconfined"
}
Thanks

I've been working on a new, much improved, version of the script that uses jq to add the ipv6 key/value pairs to the json files. This will prevent changing any existing custom settings in the json files.
But at the moment it sometimes results in an empty /var/packages/ContainerManager/target/config/dockerd.json

Do you want to try the new v2.0.4

@007revad The new script 2.0.4 is working like a charm! B-) I have now IPv6 enabled. Thank you so much!!!
Last question.. did you resolve how to support IPv6 on host network driver?

Excellent.
From this https://docs.docker.com/config/daemon/ipv6/ webpage it looks like you can only enable IPv6 on the bridge network, or create a new IPv6 network via docker compose.


feat[prerequisites]: serviceAccount for gcloud-sqlproxy

To be able to use the GCloud SQL Proxy with IAM authentication we want to specify a certain serviceAccount that has the needed IAM permissions
Checklist

[x] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[x] Links to related issues (if applicable)
[x] Tests for the changes have been added/updated (if applicable)
[x] Docs related to the changes have been added/updated (if applicable)

ty

@norman-zon @david-leifker Hi! This works like a charm when installing the prerequisites. But maybe you can help me on what to do in the global.sql.datasource part of values.yaml from the datahub helm chart? It asks for a password, but I want to authenticate via IAM through the proxy installed in the prerequisites.
So when I try to install Datahub itself, it gives this error:
psql: error: connection to server at "prerequisites-gcloud-sqlproxy" (10.x.x.192), port 5432 failed: FATAL:  password authentication failed for user "sa-datahub-dev"
Thanks for any help!


[Question] i get ki

Checks

[X] I confirm that I have searched for existing issues / pull requests before reporting to avoid duplicate reporting.
[X] I confirm that I noted that if I don't follow the instructions, the issue may be closed directly.

Description
Every time I want to send a message on the Minecraft internal chat, I get kicked out from the server :/.
log:
MrShishGod lost connection: Internal Exception: java.lang.IllegalArgumentException: Expected URL scheme 'http' or 'https' but no scheme was found for 100522...
[15:02:52] [Server thread/INFO]: MrShishGod left the game
[15:02:53] [Server thread/INFO]: Disconnecting client MrShishGod

it is the first time I put this mod on my server. thanks for any help

What Minecraft version are you using? Please try the latest build. If the issue still exists, please upload the full latest.log here.

ah sorry for not writing it, i am using the 1.19

1.19.0?

yes

Are you able to update your server to 1.19.2? The latest build is not compatible with 1.19.0

wait for me to try, thanks for help.

Ok

Sorry for waiting, but the servers I use were down to their own problem and I couldn't log in
(I use falix).
I searched online, but I can't find fabric for 1.19.2

Fabric installer is here: https://fabricmc.net/use/installer/

Ok, I installed 1.19.2, and it works.
Thank you. :)

Ok nice


Help! Deployment always failed.

when I finished the command "docker-compose up -d", all the components started. However I can't visit "http://tourguide", and I use "docker-compose ps" to check state of all components. The result were "cygnus       /docker-entrypoint.sh         Exit 1"   and  "ul20client           /docker- entrypoint.sh--acpi         Exit 1"

Hi, could you provide the following information, please?

version of TourGuide (master, develop, release (e.g. 0.5.1))
operating system
output of the docker-compose logs command (create a gist/pastebin and put the url here, do not paste the output directly in the issue)

Also, make sure you have the latest images for the version you're using via docker-compose pull.
There's a pending PR (#118) that will replace our custom cygnus image with the official image and that should fix the cygnus container exiting.
The problem with ul20client, without seeing the logs is hard to guess.
Thank you.

Thank you for your answer in time, and I so sorry for my late reply due to some urgent things  to deal with and bad network environment to update components in China.
Using your method, I have solved the problem related to cygnus, but  another problem still exists.
Here is the information:

version of TourGuide is develop
OS is ubuntu 14.04
Although I have fix the hosts, I can't use gist to create a gist in China. Because the log is big(1.8M), so I upload  screen.log. If I find the way to create a gist, I will upload it in time.

Thank you for your help again.

The following is just a guess, but we've seen it before on some systems.
The ul20client container uses the acpi subsystem by default.  If the system where your're running the containers does not support it, it will fail.  Modify the command directive on the docker-compose.yml file for that container from:
command: --acpi

to:
command: --fake --min 0 --max 100 --variance 5

This will create a fake sensor instead of trying to use the ones available on the system, with a minimum value of 0, a maximum of 100 and varying +/-5 between each reading at random.

Thank you for your answer.
When I modified the docker-compose.yml, the result was still Exit1
ul20client:
    image: bitergia/ul20-client:latesct
    hostname: ul20client
    container_name: ul20client
    links:
        - orion
        - idas
    command: --fake --min 0 --max 100 -variance 5
    environment:
        - UL20_IOTA_HOST=idas
        - UL20_IOTA_PORT=7896
        - UL20_IOTA_ADMIN_PORT=4041
        - UL20_API_KEY=tourguide-devices
        - UL20_SERVICE_NAME=tourguide

I am expected to introduce more about what I am doing. I am doing this tourguide on Virtual Machine with Ubuntu 14.04, and it doesn't feed any sensor to this program nowadays. What I do is following the the tourguide introduction and I can't get guiding from surrounding people or Chinese documents. So I think I may do something wrong in this process and I don't know that.
If it works and we put it in practical projects, I think fiware will popularize to some extent in China.
Thank you for your help. @dmabtrg

You are missing a - in --variance.  It should have two - instead of one.
If that doesn't solve it, try docker logs ul20client | tail -n 20.  That will show the last 20 lines of the log of that container and probably show the error.  Paste that lines here if it's still failing.

Adding a -, it still doesn't work.
The log is :
root@ubuntu:/home/tyrion/fiware# docker logs ul20client | tail -n 20
* Asking to http://idas:4041/iot/services
* Headers: {'Fiware-Service': 'tourguide', 'content-type': 'application/json', 'Fiware-ServicePath': '/', 'X-Auth-Token': 'NULL'}
* Sending PAYLOAD:
{
    "services": [
        {
            "token": "token2",
            "apikey": "tourguide-devices",
            "resource": "/iot/d",
            "entity_type": "thing",
            "cbroker": "http://orion:1026"
        }
    ]
}

...

* Status Code: 409
* Response:
{"name":"DUPLICATE_GROUP","message":"A device configuration already exists for resource /iot/d and API Key tourguide-devices"}

Ok.  The first thing the container does is try to register the service with the IoT Agent (the idas container), and this is what it's failing now.  The message shows that the service already exists (and this will stop the container).  Could you try again by removing the old containers first?    After this, you can start a new set of containers with
docker-compose up -d

Please note that the ul20client container is a simple client for the IoT Agent and this functionality is now integrated in the main TourGuide application, so this container might be removed in the future.  If you're still having problems with this container, you can disable it completely by commenting the ul20client section in the docker-compose.yml file.
Hope that helps.

After doing what you tell me, using command docker-compose ps showed status of all components were up, but I can't still visit http://tourguide.
I have run the ./get-docker-hosts.
root@ubuntu:/home/tyrion/fiware/docker/docker/utils# ./get-docker-hosts
2016/08/10 18:49:09 +0800	OS: Linux
2016/08/10 18:49:09 +0800	Using hosts file '/etc/hosts'
### BEGIN Docker container IPs ###
<IP_ADDRESS>    tourguide tourguide
<IP_ADDRESS>    ul20client ul20client
<IP_ADDRESS>    cygnus compose_cygnus_1 cygnus cygnus_1
<IP_ADDRESS>    idas compose_idas_1 idas idas_1
<IP_ADDRESS>    orion compose_orion_1 orion orion_1
<IP_ADDRESS>    keyrock keyrock
<IP_ADDRESS>    authzforce authzforce
<IP_ADDRESS>    mongodb compose_mongodb_1 mongo mongodb mongodb_1
<IP_ADDRESS>    mysql mysql
### END Docker container IPs ###

Visiting http://tourguide still failed.
Then I visit <IP_ADDRESS>, and the website directly go to ````<IP_ADDRESS>/client/which shows a map and a buttonlog in. However when I click this button, webpage showed 404 not foundand website wastourguide/auth```. After doing this, I try to visit other ip(<IP_ADDRESS>-<IP_ADDRESS>), but all pages can't be visited.
Thank you for your patience and guiding. @dmabtrg

You should pass the -m flag to get-docker-hosts to actually modify the /etc/hosts file.  If you don't, it will show what will be added, but will not modify the file.

Thank you. @dmabtrg
It works, and I will be more  careful what I do.

Ok.  I'm closing the issue then.


Update to 1.9.3 fails

Describe the bug
Using http://homeassistant.local:8123/hassio/addon/982ee2c4_volvo2mqtt/info
When pressing update it results in this error:

Version info:
(You have 1.8.27 installed. Click update to update to version 1.9.3)
Core 2024.6.0b8

You are on B6, are u able to update the addon on the latest stable HA update ?

Hi Linus, I went back to version 2024.5.5, same problem.
Cheers
Ben

From: Linus Dietz @.>
Sent: Wednesday, 5 June 2024 15:10
To: Dielee/volvo2mqtt @.>
Cc: Ben Geerdes @.>; Author @.>
Subject: Re: [Dielee/volvo2mqtt] Update to 1.9.3 fails (Issue #201)
You are on b8, are u able to update the addon on the latest stable HA update ?
—
Reply to this email directly, view it on GitHubhttps://github.com/Dielee/volvo2mqtt/issues/201#issuecomment-2149848935, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAKBN422W3RZ2KRHLARWVYDZF4E37AVCNFSM6AAAAABI2VWCQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBZHA2DQOJTGU.
You are receiving this because you authored the thread.Message ID: @.***>

So please send me your supervisor logs from plugin install

2024-06-05 15:17:25.693 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration asusrouter which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-06-05 15:17:25.696 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration localtuya which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-06-05 15:17:25.698 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-06-05 15:17:25.700 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration mitsubishi_wf_rac which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2024-06-05 15:17:39.457 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'hacs' accesses hass.components.frontend. This is deprecated and will stop working in Home Assistant 2024.9, it should be updated to import functions used from frontend directly at custom_components/hacs/frontend.py, line 68: hass.components.frontend.async_register_built_in_panel(, please create a bug report at https://github.com/hacs/integration/issues
2024-06-05 15:17:41.108 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] CURRENT_HVAC_HEAT was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use HVACAction.HEATING instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.116 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] CURRENT_HVAC_IDLE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use HVACAction.IDLE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.124 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] HVAC_MODE_AUTO was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use HVACMode.AUTO instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.132 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] HVAC_MODE_HEAT was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use HVACMode.HEAT instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.140 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] HVAC_MODE_OFF was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use HVACMode.OFF instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.148 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] SUPPORT_PRESET_MODE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use ClimateEntityFeature.PRESET_MODE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.158 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] SUPPORT_TARGET_TEMPERATURE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use ClimateEntityFeature.TARGET_TEMPERATURE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.167 WARNING (ImportExecutor_0) [homeassistant.components.climate.const] SUPPORT_TARGET_TEMPERATURE_RANGE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use ClimateEntityFeature.TARGET_TEMPERATURE_RANGE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.175 WARNING (ImportExecutor_0) [homeassistant.const] TEMP_CELSIUS was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use UnitOfTemperature.CELSIUS instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.184 WARNING (ImportExecutor_0) [homeassistant.const] TEMP_FAHRENHEIT was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use UnitOfTemperature.FAHRENHEIT instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.198 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_CLOSE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.CLOSE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.207 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_OPEN was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.OPEN instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.216 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_SET_POSITION was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.SET_POSITION instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.224 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_STOP was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.STOP instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.231 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_CLOSE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.CLOSE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.242 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_OPEN was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.OPEN instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.250 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_SET_POSITION was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.SET_POSITION instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.258 WARNING (ImportExecutor_0) [homeassistant.components.cover] SUPPORT_STOP was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use CoverEntityFeature.STOP instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.285 WARNING (ImportExecutor_0) [homeassistant.components.fan] SUPPORT_DIRECTION was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use FanEntityFeature.DIRECTION instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.292 WARNING (ImportExecutor_0) [homeassistant.components.fan] SUPPORT_OSCILLATE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use FanEntityFeature.OSCILLATE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.300 WARNING (ImportExecutor_0) [homeassistant.components.fan] SUPPORT_SET_SPEED was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use FanEntityFeature.SET_SPEED instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.309 WARNING (ImportExecutor_0) [homeassistant.components.fan] SUPPORT_DIRECTION was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use FanEntityFeature.DIRECTION instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.316 WARNING (ImportExecutor_0) [homeassistant.components.fan] SUPPORT_OSCILLATE was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use FanEntityFeature.OSCILLATE instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.326 WARNING (ImportExecutor_0) [homeassistant.components.fan] SUPPORT_SET_SPEED was used from localtuya, this is a deprecated constant which will be removed in HA Core 2025.1. Use FanEntityFeature.SET_SPEED instead, please report it to the author of the 'localtuya' custom integration
2024-06-05 15:17:41.732 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'localtuya' accesses hass.helpers.service. This is deprecated and will stop working in Home Assistant 2024.11, it should be updated to import functions used from service directly at custom_components/localtuya/init.py, line 164: hass.helpers.service.async_register_admin_service(, please create a bug report at https://github.com/rospogrigio/localtuya/issues
2024-06-05 15:17:42.323 WARNING (ImportExecutor_0) [homeassistant.helpers.typing] HomeAssistantType was used from mitsubishi_wf_rac, this is a deprecated alias which will be removed in HA Core 2025.5. Use homeassistant.core.HomeAssistant instead, please report it to the author of the 'mitsubishi_wf_rac' custom integration
2024-06-05 15:17:42.347 WARNING (ImportExecutor_0) [homeassistant.helpers.typing] HomeAssistantType was used from mitsubishi_wf_rac, this is a deprecated alias which will be removed in HA Core 2025.5. Use homeassistant.core.HomeAssistant instead, please report it to the author of the 'mitsubishi_wf_rac' custom integration
2024-06-05 15:17:42.504 WARNING (ImportExecutor_0) [homeassistant.helpers.typing] HomeAssistantType was used from mitsubishi_wf_rac, this is a deprecated alias which will be removed in HA Core 2025.5. Use homeassistant.core.HomeAssistant instead, please report it to the author of the 'mitsubishi_wf_rac' custom integration
2024-06-05 15:17:45.877 WARNING (ImportExecutor_0) [py.warnings] /usr/local/lib/python3.12/site-packages/plexapi/base.py:183: SyntaxWarning: invalid escape sequence '\d'
""" Load the specified key to find and build all items with the specified tag
2024-06-05 15:17:46.769 WARNING (ImportExecutor_0) [homeassistant.helpers.typing] HomeAssistantType was used from mitsubishi_wf_rac, this is a deprecated alias which will be removed in HA Core 2025.5. Use homeassistant.core.HomeAssistant instead, please report it to the author of the 'mitsubishi_wf_rac' custom integration
2024-06-05 15:18:01.705 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [547926584640] Unexpected exception
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/hassio/update.py", line 168, in async_install
await async_update_addon(self.hass, slug=self._addon_slug, backup=backup)
File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 59, in _wrapper
data = await funct(*argv, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 136, in async_update_addon
return await hassio.send_command(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 593, in send_command
raise HassioAPIError(error.get(ATTR_MESSAGE))
homeassistant.components.hassio.handler.HassioAPIError: The command '/bin/ash -o pipefail -c apk add --no-cache python3 bash py3-pip' returned a non-zero code: 3
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 239, in handle_call_service
response = await hass.services.async_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2738, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2779, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 975, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1047, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/update/init.py", line 157, in async_install
await entity.async_install_with_progress(version, backup)
File "/usr/src/homeassistant/homeassistant/components/update/init.py", line 461, in async_install_with_progress
await self.async_install(version, backup)
File "/usr/src/homeassistant/homeassistant/components/hassio/update.py", line 170, in async_install
raise HomeAssistantError(f"Error updating {self.title}: {err}") from err
homeassistant.exceptions.HomeAssistantError: Error updating Volvo2Mqtt: The command '/bin/ash -o pipefail -c apk add --no-cache python3 bash py3-pip' returned a non-zero code: 3
2024-06-05 15:18:05.038 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'hacs' accesses hass.helpers.event. This is deprecated and will stop working in Home Assistant 2024.11, it should be updated to import functions used from event directly at custom_components/hacs/base.py, line 642: self.hass.helpers.event.async_track_time_interval(, please create a bug report at https://github.com/hacs/integration/issues
2024-06-05 15:18:33.123 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [547926584640] Unexpected exception
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/hassio/update.py", line 168, in async_install
await async_update_addon(self.hass, slug=self._addon_slug, backup=backup)
File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 59, in _wrapper
data = await funct(*argv, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 136, in async_update_addon
return await hassio.send_command(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/hassio/handler.py", line 593, in send_command
raise HassioAPIError(error.get(ATTR_MESSAGE))
homeassistant.components.hassio.handler.HassioAPIError: The command '/bin/ash -o pipefail -c apk add --no-cache python3 bash py3-pip' returned a non-zero code: 3
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 239, in handle_call_service
response = await hass.services.async_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2738, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2779, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 975, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1047, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/update/init.py", line 157, in async_install
await entity.async_install_with_progress(version, backup)
File "/usr/src/homeassistant/homeassistant/components/update/init.py", line 461, in async_install_with_progress
await self.async_install(version, backup)
File "/usr/src/homeassistant/homeassistant/components/hassio/update.py", line 170, in async_install
raise HomeAssistantError(f"Error updating {self.title}: {err}") from err
homeassistant.exceptions.HomeAssistantError: Error updating Volvo2Mqtt: The command '/bin/ash -o pipefail -c apk add --no-cache python3 bash py3-pip' returned a non-zero code: 3
2024-06-05 15:18:56.840 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.airco is taking over 10 seconds
2024-06-05 15:20:10.431 WARNING (Recorder) [homeassistant.components.sensor.recorder] The unit of sensor.volvo_yv1xzedv6p2944143_estimated_charging_time (min) cannot be converted to the unit of previously compiled statistics (minutes). Generation of long term statistics will be suppressed unless the unit changes back to minutes or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
2024-06-05 15:26:56.854 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.airco is taking over 10 seconds
2024-06-05 15:27:17.430 ERROR (MainThread) [custom_components.mitsubishi_wf_rac.wfrac.device] Error: something went wrong updating the airco [Airco] values

From: Linus Dietz @.>
Sent: Wednesday, 5 June 2024 15:24
To: Dielee/volvo2mqtt @.>
Cc: Ben Geerdes @.>; Author @.>
Subject: Re: [Dielee/volvo2mqtt] Update to 1.9.3 fails (Issue #201)
So please send me your supervisor logs from plugin install
—
Reply to this email directly, view it on GitHubhttps://github.com/Dielee/volvo2mqtt/issues/201#issuecomment-2149910187, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAKBN45AESTBGQSIW46PFH3ZF4GSJAVCNFSM6AAAAABI2VWCQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBZHEYTAMJYG4.
You are receiving this because you authored the thread.Message ID: @.***>

I have almost the same error, reurns 2 instead of 3. I'm submitting my supervisor log below.
2024-06-07 10:37:09.369 INFO (MainThread) [supervisor.docker.addon] Updating image 982ee2c4/aarch64-addon-volvo2mqtt:1.8.27 to 982ee2c4/aarch64-addon-volvo2mqtt:1.9.3
2024-06-07 10:37:09.372 INFO (MainThread) [supervisor.docker.addon] Starting build for 982ee2c4/aarch64-addon-volvo2mqtt:1.9.3
2024-06-07 10:37:21.419 ERROR (MainThread) [supervisor.docker.addon] Can't build 982ee2c4/aarch64-addon-volvo2mqtt:1.9.3: The command '/bin/ash -o pipefail -c apk add --no-cache python3 bash py3-pip' returned a non-zero code: 2
2024-06-07 10:37:21.419 ERROR (MainThread) [supervisor.docker.addon] Build log:
Step 1/15 : ARG BUILD_FROM

Step 2/15 : FROM $BUILD_FROM

 ---> 3050c2ba69b9

Step 3/15 : RUN apk add --no-cache python3 bash py3-pip

 ---> Running in 586a5ddeaede

fetch https://dl-cdn.alpinelinux.org/alpine/v3.20/main/aarch64/APKINDEX.tar.gz

WARNING: fetching https://dl-cdn.alpinelinux.org/alpine/v3.20/main: temporary error (try again later)

fetch https://dl-cdn.alpinelinux.org/alpine/v3.20/community/aarch64/APKINDEX.tar.gz

WARNING: fetching https://dl-cdn.alpinelinux.org/alpine/v3.20/community: temporary error (try again later)
ERROR: unable to select packages:
  py3-pip (no such package):
    required by: world[py3-pip]
  python3 (no such package):
    required by: world[python3]

 ---> Removed intermediate container 586a5ddeaede

So it looks like the apline base container isn't available at this time. As said in the message, please try again later.
This isn't a volvo2mqtt issue....

Yes, I can download it from my HA server:
➜  ~ wget https://dl-cdn.alpinelinux.org/alpine/v3.20/main/aarch64/APKINDEX.tar.gz
--2024-06-08 09:16:52--  https://dl-cdn.alpinelinux.org/alpine/v3.20/main/aarch64/APKINDEX.tar.gz
Resolving dl-cdn.alpinelinux.org (dl-cdn.alpinelinux.org)... <IP_ADDRESS>, 2a04:4e42:14::644
Connecting to dl-cdn.alpinelinux.org (dl-cdn.alpinelinux.org)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 473156 (462K) [application/octet-stream]
Saving to: 'APKINDEX.tar.gz'

APKINDEX.tar.gz                          100%[===============================================================================>] 462.07K  --.-KB/s    in 0.02s

2024-06-08 09:16:52 (20.0 MB/s) - 'APKINDEX.tar.gz' saved [473156/473156]

And addon install isn't working?

Still not for me.
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: Linus Dietz @.>
Sent: Saturday, June 8, 2024 9:30:11 AM
To: Dielee/volvo2mqtt @.>
Cc: Ben Geerdes @.>; Author @.>
Subject: Re: [Dielee/volvo2mqtt] Update to 1.9.3 fails (Issue #201)
And addon install isn't working?
—
Reply to this email directly, view it on GitHubhttps://github.com/Dielee/volvo2mqtt/issues/201#issuecomment-2155854714, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAKBN43IR5J4FVQZQRF27VTZGKXIHAVCNFSM6AAAAABI2VWCQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJVHA2TINZRGQ.
You are receiving this because you authored the thread.Message ID: @.***>

This looks like a local problem, for me everything is working. I don't know why your updates don't work.

And now it just worked...
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: Linus Dietz @.>
Sent: Saturday, June 8, 2024 3:47:07 PM
To: Dielee/volvo2mqtt @.>
Cc: Ben Geerdes @.>; Author @.>
Subject: Re: [Dielee/volvo2mqtt] Update to 1.9.3 fails (Issue #201)
This looks like a local problem, for me everything is working. I don't know why your updates don't work.
—
Reply to this email directly, view it on GitHubhttps://github.com/Dielee/volvo2mqtt/issues/201#issuecomment-2156043452, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAKBN4ZMZWHMVSLSE3L2ETLZGMDNXAVCNFSM6AAAAABI2VWCQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGA2DGNBVGI.
You are receiving this because you authored the thread.Message ID: @.***>

I tried an uninstall, which worked. Then, whenre- installing, I get the same error as when updating :-( I'll start going through my logs to see if Alpine is referenced from or mentioned somewhere else.

It now just worked for me...
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: Michael Westlund @.>
Sent: Saturday, June 8, 2024 9:03:11 PM
To: Dielee/volvo2mqtt @.>
Cc: Ben Geerdes @.>; Author @.>
Subject: Re: [Dielee/volvo2mqtt] Update to 1.9.3 fails (Issue #201)
I tried an uninstall, which worked. Then, whenre- installing, I get the same error as when updating :-( I'll start going through my logs to see if Alpine is referenced from or mentioned somewhere else.
—
Reply to this email directly, view it on GitHubhttps://github.com/Dielee/volvo2mqtt/issues/201#issuecomment-2156142290, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAKBN42YIK3TQDJHQ4327F3ZGNIO7AVCNFSM6AAAAABI2VWCQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGE2DEMRZGA.
You are receiving this because you authored the thread.Message ID: @.***>

According to the log I had data for about 6 hours, since then I have this:

If you have an issue, please open up a new issue and provide logs!

Sorry, I thought that only went to you, not github.

The error persisted for about one week so I gave up after tracing log files and relationships to other libraries, considering my next step. Then, suddenly and without any changes to Home Assistant (by me) the update was successful.

This bug has re-emerged, I get
The command '/bin/ash -o pipefail -c apk add --no-cache python3 bash py3-pip' returned a non-zero code: 2
when I try to update from 1.9.5 to 1.9.6 :(
Supervisor log
2024-08-23 12:30:35.473 ERROR (MainThread) [supervisor.docker.addon] Can't build 982ee2c4/aarch64-addon-volvo2mqtt:1.9.6: The command '/bin/ash -o pipefail -c apk add --no-cache python3 bash py3-pip' returned a non-zero code: 2
2024-08-23 12:30:35.474 ERROR (MainThread) [supervisor.docker.addon] Build log:
Step 1/15 : ARG BUILD_FROM

Step 2/15 : FROM $BUILD_FROM

 ---> 5323f8eef0b6

Step 3/15 : RUN apk add --no-cache python3 bash py3-pip

 ---> Running in 8e0cf987a122

fetch https://dl-cdn.alpinelinux.org/alpine/v3.20/main/aarch64/APKINDEX.tar.gz

WARNING: fetching https://dl-cdn.alpinelinux.org/alpine/v3.20/main: temporary error (try again later)

fetch https://dl-cdn.alpinelinux.org/alpine/v3.20/community/aarch64/APKINDEX.tar.gz

**WARNING: fetching https://dl-cdn.alpinelinux.org/alpine/v3.20/community: temporary error (try again later)**

ERROR: unable to select packages:
  py3-pip (no such package):
    required by: world[py3-pip]
  python3 (no such package):
    required by: world[python3]

 ---> Removed intermediate container 8e0cf987a122

My system
Core 2024.8.2
Supervisor 2024.08.0
Operating System 13.1
Frontend 20240809.0

The error has persisted since the 1.9.6 upgrade. At the time I was running a Home Assistant Green with Core 2024.7.0+, which I updated to Yellow restoring a backup to it.
When I try fetching https://dl-cdn.alpinelinux.org/alpine/v3.20/community/aarch64/APKINDEX.tar.gz with curl it works, I can download the file to both my HA instance as well as locally on my client (Mac OS) using
curl -o file.tar.gz https://dl-cdn.alpinelinux.org/alpine/v3.20/community/aarch64/APKINDEX.tar.gz
I have waited a few weeks to see if this eventually disappears, but to no avail. Any clue where to look next or if this is an issue for the core or supervisor teams?
/ Mike


Uses one test-requirements file for the project

Description
One test-requirements file is added at the root of the project to be used by tox for all charms.
Checklist

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have made corresponding changes to the documentation.
[ ] I have added tests that validate the behaviour of the software.
[x] I validated that new and existing unit tests pass locally with my changes.
[x] Any dependent changes have been merged and published in downstream modules.
[ ] I have bumped the version of any required library.

The description of the PR does not seem to match the title or the content. Otherwise, LGTM

I updated the description :)


Global mapping solution

Build out a more complete geo offering, including:

Global Choropleth: countries level, and sub-national jurisdictions
Heatmaps
Map pins

ECharts quite good for cases 1 and 2, but it may be worth exploring leaflet, mapbox or similar


IMPORTANT: SEE HERE FOR CONTROLLER PROBLEMS ON QUEST

Since @polygraphene is nowhere to be seen, I'm leaving this here for people who are coming here and asking this question over and over since I have no good resource to point them to. #479 #477 #476 #484
A bit over a week ago, a firmware update for Oculus Quest was released that apparently introduced some kind of compatibility for Oculus Go / Gear VR which activates if the app does not declare the android.hardware.vr.headtracking feature. In the past it was only really required when submitting the app to the store to pass certification and missing it out didn't break anything, hence why most sideloaded apps failed to do it properly.
The compatibility mode allows only one controller to be active at a time and makes it appear to the program as the Oculus Go controller rather than the normal Quest one (which also limits the available input buttons)
I submitted a pull request to fix it in https://github.com/polygraphene/ALVRClient/pull/32, but until @polygraphene comes back to merge it and make an official release, you will have to get a patched version from somewhere. I've seen a few of these around, but since I don't generally trust random binaries from the internet so here is a build I made myself from the master branch with this fix included: https://github.com/krzys-h/ALVRClient/releases/tag/v2.4.0-alpha5-quest-fix

tl;dr, if you are not a developer and don't care about the technical things, here is what to do to get it to work again. I'll assume you already know how to use adb since you somehow managed to install the official, broken version (if not, see https://github.com/polygraphene/ALVR/wiki/Installation)

Download a patched version from https://github.com/krzys-h/ALVRClient/releases/tag/v2.4.0-alpha5-quest-fix
adb uninstall com.polygraphene.alvr (this has to be done explicitly since the patched version uses different signing keys because obviously nobody except @polygraphene has the official ones)
adb install path-to-patched-version.apk

PS. Apparently somebody is working on a version which contains this fix as well as some other improvements to controller tracking (see #482) although I haven't tested it so YMMV

@krzys-h Thanks for the reference, but this actually has nothing to do with what I meant =P I knew about that one error, mine is a completely different one which was there even before the update for the "Go" compatibility.
Anyway, as I said, thanks for the reference and the post itself, which I'm sure it'll help lots of users.

@Irtharan I know yours is different, the reason it appeared to you is because I put a link to the fork with various improvements at the end of the post

@krzys-h Ohh okay, sorry. Totally new into github, so dunno about how it totally works still ^^'

Wish I'd seen this post two days ago, I already made my own patched apk for a friend X_X

Thanks for taking the time to do this.  Works as expected all the controls in Google Earth work as expected.

Wow. Thanks for the revised version. However, While I was using my Oculus Touch Controller (Not Oculus Rift one), Oculus Rift controller appears rather than Oculus Touch controller (Bundled with Quest) in SteamVR Home (And also some kind of mismatch happens at controller tracking). But when I use SteamVR overlay and any other apps (like SteamVR tutorial) controllers seems fine. I dont know why this happens.

this version linked is not seen by the alvr server, while the official version was found, but controllers didnt work

images very far apart, help?

Hi everyone,
is there a newer version? This doesn't seem to work. I am connected to the server, I am in the Steam Home but do not see any controllers or even hands.
I installed
"app-Github-Normal-Ovr-debug.apk" on the glasses and
"v2.4.0-alpha5" server app
greetings
the Lexx

Are you certain that you do not have the long press enabled?
See: https://www.reddit.com/r/oculus/comments/awv1iv/oculus_touch_controller_oculushome_button_not/

im still having trouble with the controllers not working once i'm in game. works in the steam vr home but not in games. help? trying to play some games, maybe even ALYX  in quarantine

im still having trouble with the controllers not working once i'm in game. works in the steam vr home but not in games. help? trying to play some games, maybe even ALYX in quarantine

i also installed the fix as suggested to no avail. programming
noob here.


Enum breaks the diagram

Description:

Adding an enum keeps the diagram loading.
Steps to reproduce:
Add an enum to the source code and try to open the diagram.
Affected Versions:
V3.3.4-beta2

Fixed with 4.x release


AYN Odin 2

I've added a line for AYN Odin, but there is one caveat that I'm not sure about.
I got the GUID by writing up a quick and dirty tool in Godot.  Basically, I have a label named PadGUID and this line of code:
$PadGUID.set_text (Input.get_joy_guid(0)) #Device GUID
The number it returned is shorter than all the ones in the database.  Here it is next to the number for my Switch controller, for comparison:
Odin 2:               4f64696e20436f6e74726f6c6c6572
My switch controller: 030000006f0e00008401000011010000

Interestingly, the number for my Odin works just fine when I feed it back into Godot with this statement:
Input.add_joy_mapping("4f64696e20436f6e74726f6c6c6572,AYN Odin 2,a:b1,b:b0,back:b4,dpdown:b12,dpleft:b14,dpright:b13,dpup:b11,leftshoulder:b9,leftstick:b7,lefttrigger:+a5,leftx:a0,lefty:a1,rightshoulder:b10,rightstick:b8,righttrigger:+a4,rightx:a2,righty:a3,start:b6,x:b3,y:b2,platform:Android,", true)
I had a slightly different version of that line, minus the Godot stuff, in an earlier, now-retracted pull request, and when I went to add in a small fix, that was when I noticed the discrepancy.  I don't want to accidentally break something with an incorrectly-formatted GUID, so I'm making sure to mention all this.  I don't know if it's an obscure bug somewhere or just the Odin devs being weird.
Things I made sure to do with this mapping:
ABXY buttons mapped by position.
Correct mapping of the left and right triggers.
Correct the minimum value on the left and right triggers.
Test the mapping in a Godot APK to make sure everything works correctly.

Also, you'll see a different GUID in the middle commit.  That was from a different tool, and using it in the Godot line didn't work.  As far as Godot is concerned, the shorter GUID seems to be the correct one.

Can you try right-padding the GUID with 0s and see if Godot still picks up the mapping ?

Can you try right-padding the GUID with 0s so it reaches a normal length and see if Godot still picks up the mapping ?

I just checked that and compiled a new APK.  That broke the mapping.  For whatever reason, the folks over at AYN gave this device a shorter GUID.

Nothing to do with AYN, something to do with Godot or how it's using SDL. GUIDs are normalized to 32 characters, there is no precedent for shorter, so I'm not going to merge this; the 30+ mappings we have that match this format are all right-padded. Feel free to try the [SDL utils] on Android if you want to unwind this further

I didn't pay attention to the padding instructions earlier and put the zeroes on the left side.  I just tried it again on the right side and it works.  I'll fix my stuff real quick.

I feel like a total noob now because of that.

Don't sweat it ! Glad we were able to work out all the kinks :-) Thanks again 👍


Refactor 'Create an exercise' journey routes and views

Trello card
This PR refactors the route configuration and renames/moves the associated page views which make up the 'Create an exercise' journey.
Refactoring has been performed based on notes in this wiki page.
URL scheme
The updated URL scheme is as follows:

URL path
Page description

/exercises/new
Create an exercise

/exercises/$ID
Details page

/exercises/$ID/edit/contacts
Add exercise contacts

/exercises/$ID/edit/shortlisting
Add shortlisting methods

/exercises/$ID/edit/timeline
Add exercise timeline

The pages 'Add vacancy information' and 'Add eligibility information' aren't yet in master so I have not moved or refactored those.
View files
View files have been moved to reflect the new URL structure. This will help us to organise our views and routes in the long term when more pages and sections are added.

A new directory views/Exercises/ contains all views specific to exercises.
The subdirectory views/Exercises/Edit/ contains edit pages for an individual exercise
The view views/Exercises/New.vue is the first page in creating a new exercise

Other things to note

I've updated the hardcoded links on the 'Save and continue' buttons so that the non-functional click-through journey for 'Create an exercise' still works.
I've refactored tests slightly to make them more consistent. This mostly was a couple of changes:

signin.spec.js now has consistent describe() block descriptions for affected pages between the 'authenticated' and 'unauthenticated' tests
Tests for each view now have one top-level describe() block where they previously had two. This involved moving the describe('Accessibility') blocks into the main block for the component.

@LaurenQurashi this PR will affect your PRs that you have in draft. Ideally we'll be able to merge this PR into master first, and then before merging yours you'll need to rename your views and router configuration to be consistent with the other pages.
I'm happy to talk this through either today or on Monday.


[as2_external_object_to_tf] default config file within the node

Basic Info

Info
Please fill out this column

Issue(s) this addresses
#563

ROS2 version tested on
Humble

Aerial platform tested on

Description of contribution in a few bullet points

Not sure about this, there should be no default configuration file for this package, or it should?


Authentication and database

What is the easiest way to handle the fact that an authentication password is required for redis and the fact that a specific database should be used?

I guess by creating your own client (like ioredis) and passing that in on instantiation?

Yes, that would be the way.


Fix spec OpenStack Cloud factory

Recent change in ems_cloud factory added region (assumed its Amazon only propably),
which broke OpenStack tests.
Changing ems_openstack parent directly to ext_management_system to bypass region setup.
Should fix OpenStack Travis.
Links

related to https://github.com/ManageIQ/manageiq/pull/18842

cc @d-m-u
Please run UI tests and API tests before merge.

api and ui repos green with this patch applied


Automatically use type="number" for expressions of more types

#2261

include short, ushort, float, double

correct typo in <input/> tag helper; ignored calculated format

only one test for <input/>'s calculated format :frowning:

fill some Editor*() and <input/> tag helper test gaps

nit: clean up some trailing whitespace

/cc @pranavkm

:shipit:

73e8fc1


[Firebase] hangs and return Error: Client is offline.

I'm using "firebase-admin": "^9.7.0" on gke, the pods have access to the internet but I got this error when trying to query documents from a real-time database.
root@pod-75d4865d87-sjz9p:/src/services# node trace.js
starting...
Error: Error: Client is offline.
at /node_modules/@firebase/database/dist/index.node.cjs.js:12813:35

be sure to check !empty and trim() the database url

How?


Inconsistent loss function from the paper?

Hi,
I don't use torch a lot and I have a question regarding the implementation of the discriminator loss at line 211, errD = errD_real - errD_fake where errD_real is the gradient of real samples (line202: errD_real.backward(one)) and errD_fake is the gradient of fake samples (errD_fake.backward(mone)). However, in the paper it seems that errD needs to be maximized while it is minimized here?
Thanks

I have the same question as you, but as I guess that because the code change the sign of both G and D loss, the discriminator just instead gives high score for fake images and low score for real images.
Intuitively, you are just changing the "label" of real and fake images.
I dont know if this is correct. Can anyone confirm this?

@npmhung , thanks for the link. I had a look at it. But there are also some other questions regarding this one. For instance, it seems that there Sigmoid has been used as the last layer for both D and G whereas in the original paper it kinda suggests that it is not? The way I understand WGAN is the clipping constrains the values, not some activation such as Sigmoid. There might be numerical consequences if activation is used but it is unclear to me either.

Can you specify the line that they use sigmoid? It seems that I can't find one.

I don't think the use of sigmoid is correct (at least for the critic net). Also, the loss functions for both D and G are the reverses of what is discussed in the paper. However, since they reverse both losses, it kinda turns out to be correct (as explained in the label flipping explanation above).

after debug a lot I found this code is not wrong, but confusing
                errD_real = netD(inputv)
                errD_real.backward(one)

                # train with fake
                noise.resize_(opt.batchSize, nz, 1, 1).normal_(0, 1)
                noisev = Variable(noise, volatile = True) # totally freeze netG
                fake = Variable(netG(noisev).data)
                inputv = fake
                errD_fake = netD(inputv)
                errD_fake.backward(mone)
                errD = errD_real - errD_fake

notice that mone here is defined as -1*one
In fact, the loss in the paper is:

so, just do backward() on the loss_d and loss_g is more easy to understand:
#for D
loss_d = errD_real.mean() - errD_fake.mean()
loss_d.backward()
#for G
loss_g = - errD_fake.mean()
loss_g.backward()

after debug a lot I found this code is not wrong, but confusing
                errD_real = netD(inputv)
                errD_real.backward(one)

                # train with fake
                noise.resize_(opt.batchSize, nz, 1, 1).normal_(0, 1)
                noisev = Variable(noise, volatile = True) # totally freeze netG
                fake = Variable(netG(noisev).data)
                inputv = fake
                errD_fake = netD(inputv)
                errD_fake.backward(mone)
                errD = errD_real - errD_fake

notice that mone here is defined as -1*one
In fact, the loss in the paper is:

so, just do backward() on the loss_d and loss_g is more easy to understand:
#for D
loss_d = errD_real.mean() - errD_fake.mean()
loss_d.backward()
#for G
loss_g = - errD_fake.mean()
loss_g.backward()

I think the loss for G should be:
#for G
loss_g = errD_fake.mean()
loss_g.backward()

as the sign changed in line 6 and 11 in the paper.

Does it mean the loss is actually has nothing to do with the label? Like -1 for a fake image.

after debug a lot I found this code is not wrong, but confusing
                errD_real = netD(inputv)
                errD_real.backward(one)

                # train with fake
                noise.resize_(opt.batchSize, nz, 1, 1).normal_(0, 1)
                noisev = Variable(noise, volatile = True) # totally freeze netG
                fake = Variable(netG(noisev).data)
                inputv = fake
                errD_fake = netD(inputv)
                errD_fake.backward(mone)
                errD = errD_real - errD_fake

notice that mone here is defined as -1*one
In fact, the loss in the paper is:

so, just do backward() on the loss_d and loss_g is more easy to understand:
#for D
loss_d = errD_real.mean() - errD_fake.mean()
loss_d.backward()
#for G
loss_g = - errD_fake.mean()
loss_g.backward()

I think the loss for G should be:
#for G
loss_g = errD_fake.mean()
loss_g.backward()

as the sign changed in line 6 and 11 in the paper.

Have you tried to modify the code in such a way? For me, this is incorrect because it will cause some problems in gradient propagation for the discriminator. I think this is due to the definition of activation functions since they are set as inplace=True. One possible solution to this is to set them to False, but I haven't tried yet.


SegmentPurger does not handle schema evolution gracefully

We ran into an issue where SegmentPurger failed due to schema evolution as follows:

New columns were added into the schema.
Table index was updated to have inverted index on some of the newly added columns.
An explicit backfill was not performed.

When the SegmentPurger tried to purge older segments, it failed with the following error:
java.lang.IllegalStateException: Cannot create inverted index for column: <xxx> because it is not in schema
This is likely because SegmentPurger used the schema in the segment as opposed to the schema in the controller.
It would be desirable for SegmentPurger to gracefully handle this scenario.

If the schema was updated with the new columns, then the schema in the controller would have the new columns right? Perhaps you meant the other way around (i.e. "used the schema in controller as opposed to the schema in the segment") ?
Speaking of which, I think it will be super useful to retain the schema evolution in zookeeper (i.e. versioned schemas with some metadata on when an update was done). It can be used to make decisions such as those by segment purger. In this case, the purger could also have decided to backfill the columns with default values, for example.

No, SegmentPurger uses the table config from controller (to identify that a it needs to build inverted index for a column), but it uses the schema in the segment and does not find the newly added column (as neither segment reload nor backfill happened), and hence the error.
Hope this answers your question.

No, SegmentPurger uses the table config from controller (to identify that a it needs to build inverted index for a column), but it uses the schema in the segment and does not find the newly added column (as neither segment reload nor backfill happened), and hence the error.
Hope this answers your question.


[TagSet]: Unable to remove tag from TagSet modal

Package
Carbon for IBM Products
Description
I was using the TagSet component with the following data structure:
[
{ label: "test", type: "gray", filter: true, onClick: removeFilter() }
]
Everything works well until I applied more than 100 tags to this component and want to see all tags and remove some of the tags with the help of the modal.
Expectation: The x (close) button in each tag inside the modal should be rendered
What happened: no x (close) button rendered
Component(s) impacted
TagSet

Browser
Chrome
@carbon/ibm-products (previously @carbon/ibm-cloud-cognitive) version
2.19.2
Severity
Severity 2 = Aspects of design is broken, and impedes users in a significant way, but there is a way to complete their tasks. Affects major functionality, has a workaround.
Product/offering
Cloud pak for data
CodeSandbox or Stackblitz example
https://codesandbox.io/p/devbox/zealous-mirzakhani-vnnhjp
Steps to reproduce the issue (if applicable)

Import TagSet
Use TagSet with > 10 data and the filter option enabled (the example uses 100 data)
Use all properties related to allTagsModal... to show the modal
Open the modal

Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

Closing as duplicate of #4358


Clarify Shareable functionality on the interface

The text in the Manage Access panel below the Shareable check box should be changed to

Check the box to let others who have access to this resource be able to share it with others at the same permission level (Edit or View) and enable adding to Collections.
Uncheck the box to prevent others from sharing the resource without the owner’s permission, or from adding the resource to Collections before the resource is made Discoverable or Public.

released in 1.36


no_std

no_std support is pretty easy, would you like a pull request? See here:
https://github.com/ibexus-platform/entrait
https://github.com/ibexus-platform/implementation

I'd accept.. Haven't verified this, but: I don't think there even needs to be a std feature flag for any of these two crates. Just add #![no_std] at the top of both crates, use ::core instead of ::std and that's even non-breaking changes in both cases and could just release minor versions updates. Do you agree?

both crates published with minor version bumps


Fallback to recompiling Kotlin scripts when classpath has public inline methods

We are not able to detect lambdas declared within inline functions, which should be treated as ABI.
Those lambdas are compiled as separate classes and we can't tell if they were declared within an inline function or not.
Until we are able to address the above, do not use compile avoidance for Kotlin buildscripts when public inline methods are used.

It's not strictly related to this PR, but I'd like to raise the concern around traceability. As a build author, I'd like to 1) convert my build to make use of compile avoidance, and 2) fix any regressions that disable this feature.
IIUC, the current implementation will only print generic messages about compile avoidance not working (e.g. Can't use compile avoidance with inline functions). It doesn't give a hint where is the problem exaclty and how to fix it.
We might want to add an extra switch, new Gradle property, etc, to collect all compile avoidance-breaking entries (without throwing an exception at the first instance) and printing their location to the console at the end of the avoidance calculation.

Follow-up for reporting compile avoidance issues: https://github.com/gradle/gradle/pull/15110


update html-tidy5 instructions

One link was dead, and it's been vastly modernized.

I just reorganised the FAQ (commit 631df93).  There seemed to be little need for a dedicated section about HTML5 these days, so I removed it completely.  All relevant information is already in the manual, and the original (HTML4) html-tidy is no longer relevant.  Thank you for the PR though.


berkeley-qa: archive node error when adding block (causes node to get stuck in catchup)

Preliminary Checks

[X] This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/MinaProtocol/mina/issues
[X] This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/MinaProtocol/mina/discussions

Description

Steps to Reproduce
Run archive node on release 1.3.1beta1-release-2.0.0-a4eae89
Expected Result
No error
Actual Result
Failure as described in description
How frequently do you see this issue?
Always
What is the impact of this issue on your ability to run a node?
High
Status
Mina daemon status
-----------------------------------

Global number of accounts:                     6410
Block height:                                  321
Max observed block height:                     326
Max observed unvalidated block height:         326
Local uptime:                                  1d2h23m5s
Ledger Merkle root:                            jxmCf6YbyFPcEjq66M9eRhGxGjuzZvQAq6xwd9sSTNAY1PePQhY
Protocol state hash:                           3NKjqA8T66VJ7YN7WHwk2peyxUPVHSjieuMTFKvQ5449r3TpaurE
Chain id:                                      44160dad015e5faabd954a053060cfe7d8ff87e8244640b0433c9374d37b9609
Git SHA-1:                                     [DIRTY]a4eae892e1019f82708d34b12164b9f51465189e
Configuration directory:                       /root/.mina-config
Peers:                                         35
User_commands sent:                            0
SNARK worker:                                  None
SNARK work fee:                                100000000
Sync status:                                   Catchup
Catchup status:
        To build breadcrumb:           0
        To initial validate:           0
        Finished:                      423
        To download:                   0
        Waiting for parent to finish:  0
        To verify:                     0

Additional information
No response

reported by @garethtdavies and @icohigh

Were the databases re-initialized before running the nodes? If the schema changed, there may be a mismatch between the archive process code and the database.
I just tried running a local network with the code in develop, and was able to archive new blocks.

Were the databases re-initialized before running the nodes? If the schema changed, there may be a mismatch between the archive process code and the database.
I just tried running a local network with the code in develop, and was able to archive new blocks.

Yes, initialised before running nodes. Everything was fine until block 291, and after it the recording stopped and there were errors in the logs.
Used schemas:
https://raw.githubusercontent.com/MinaProtocol/mina/a4eae892e1019f82708d34b12164b9f51465189e/src/app/archive/create_schema.sql
https://raw.githubusercontent.com/MinaProtocol/mina/a4eae892e1019f82708d34b12164b9f51465189e/src/app/archive/zkapp_tables.sql

The best way to debug this is to see the SQL command that caused the error.
The archive process should produce logs with that info, or it may be available in the Postgresql logs (maybe in /var/log/postgresql).