Explore options for POD access to cc_kbc

This draft is to start a discussion on how we can expose Attestation Agent to PODs, so we can do attestation + retrieve secrets at runtime.
related to #773

Previously, kata-agent was invoked using nsenter to run in the podns network namespace (#95 ), and now it runs  on the host network namespace (#155) to address #109.
I am wondering whether it is OK to launch attestation-agent as a systemd service, since it is originally launched as a child process of kata-agent.
https://github.com/kata-containers/kata-containers/blob/2b8e241179be21c7af32802222f6d47d8cc2085b/src/agent/src/image_rpc.rs#L106C8-L112
Before image.rs was introduced, kata-agent launched skopeo pull images. skopeo was needed to run on the host network space, while kata-agent ran on the podns namespace. To work around the issue, we used a wrapper skopeo script like this (#107 )
exec nsenter --target 1 --net /usr/local/bin/skopeo.bin "$@"

We may use similar approach for attestation-agent, If the systemd service approach does not work.

I needed to install tpm2-tools package on ubuntu to be able to run the attestation-agent on it:
diff --git azure/image/azure-ubuntu.pkr.hcl azure/image/azure-ubuntu.pkr.hcl
index 002478e..520b634 100644
--- azure/image/azure-ubuntu.pkr.hcl
+++ azure/image/azure-ubuntu.pkr.hcl
@@ -49,6 +49,15 @@ build {
     ]
   }

+  provisioner "shell" {
+    inline = [
+      "sudo apt-get update -y && sudo apt-get install -y tpm2-tools",
+      "sudo apt-get remove unattended-upgrades -y",
+      "sudo apt autoremove -y --purge snapd",
+      "sudo apt-get clean",
+    ]
+  }
+
   provisioner "shell" {
     execute_command = "chmod +x {{ .Path }}; {{ .Vars }} sudo -E sh '{{ .Path }}'"
     inline = [

Then I can reach to the attestation-agent from within the pod:
$ k exec -it nginx-86fcc9854-2g7cz bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
I have no name!@nginx-86fcc9854-2g7cz:/opt/bitnami/nginx/html$ curl localhost:60001
curl: (56) Recv failure: Connection reset by peer
@I have no name!@nginx-86fcc9854-2g7cz:/opt/bitnami/nginx/html$ curl localhost:60000
curl: (56) Recv failure: Connection reset by peer
@I have no name!@nginx-86fcc9854-2g7cz:/opt/bitnami/nginx/html$

@mkulke I think we can add the attestation-agent service in the podvm image creation and provide some example pods to use the AA.
To summarise

The standalone attestation-agent  will be used by image-rs for signature verification or getting image decryption keys or registry access keys
The attestation-agent service running in the pod namespace will be used by the application to kickstart attestation and retrieve secrets.

Does this sound reasonable ?
cc @surajssd @stevenhorsman @yoheiueda for their thoughts.

@mkulke I think we can add the attestation-agent service in the podvm image creation and provide some example pods to use the AA. To summarise

The standalone attestation-agent  will be used by image-rs for signature verification or getting image decryption keys or registry access keys
The attestation-agent service running in the pod namespace will be used by the application to kickstart attestation and retrieve secrets.

Does this sound reasonable ?
cc @surajssd @stevenhorsman @yoheiueda and others for their thoughts.

Yeah, that might be the best way forward, if the net ns configuration for kata-agent causes problems. The non-peerpod kata-cc pods would still retrieve secrets at runtime via the AA instance that kata-agent spawned, right? Does it make sense to reconfigure the kata-agent,image-rs, etc to spawn AA on a different port? So that the standard coco documentation w/ the default port still applies?

To me running two AA processes feel wasteful.
Kata-agent will invoke AA only when encyrpted image is used. So a long-running AA process is a side-effect and not intentional. Ideally kata-agent should kill the process after it is done.
But if we need a long-running process there should be a way to tell the kata-agent we need that and it can invoke AA and keep it running for the lifetime of the kata-agent process (hence CVM pod). This way kata-agent can use the AA as it needs and similarly workloads can use the AA as they need.
In a non-systemd (regular non-caa) VM this is fine since kata is "the" init process. But in CAA peer pod VM we should tell kata-agent to not bother about starting AA because it will already be started by something else, like systemd. Now I am not sure if we should create this third route at all? Because it might complicate the kata user interface.
Finally, I think having a flag to tell kata-agent to start AA as it starts and keep it running is a cleaner way. That way we have one process of AA running. It is intentional and not a side effect. We don't have to bother about updating documentation anywhere. On the CAA side we don't have to bother about starting a systemd process.

Kata-agent will invoke AA only when encyrpted image is used. So a long-running AA process is a side-effect and not intentional. Ideally kata-agent should kill the process after it is done.

Even when the image needs to be pulled from an authenticated registry, AA needs to be used. So AA will be invoked when pulling images from authenticated registries as well as encrypted (and signed) images.
Another aspect to consider is AA supporting different KBCs. For example using offline kbc when pulling images from authenticated registry. And supporting vTPM for workloads.
In case of OpenShift even the "pause" image comes from an authenticated registry. This secret is available to all the cluster nodes and the same is added to the pod VM via user data. Likewise for any other images which requires ImagePullSecrets, the secret is made available to the pod VM via user data.
I'm not sure if it's possible today for single AA to use different KBCs.  Although both registry secrets and workload secrets should be able to use the same KBC.
But in the short term I think we can keep the AA used with kata-agent separate from  the AA used with workloads.
It'll give us some flexibility to iron out different user workflows before arriving at a single solution.
With that said, here is a modified version of the suggestions posted by @mkulke

kata-agent should keep spawning AA (also for CAA), but a bit more explicitly - No change.
There is a systemd managed AA running in pod VM (in podns namespace) enabling workloads to use AA
we sort out the net ns problems, so pods can talk to kata-agent's AA process - We park this for now and let kata-agent AA handle image secrets (registry access, decryption/signing key) using the offline_fs_kbc (current mechanism)

I'm not sure if it's possible today for single AA to use different KBCs. Although both registry secrets and workload secrets should be able to use the same KBC.

afaik, that should be possible. the features offline_fs_kbc and cc_kbc are cumulative. you select the kbc impl using the KbcName param in a GetResourceRequest call.

kata-agent of a peer pod VM runs in the host network namespace, while containers runs in the dedicated namespace podns. This is because I want to isolate network activities of the host-side network namespace, where agent-protocol-forwarder communicates with a worker node using TCP.
In the original Kata design, kata-agent and kata-shim communicates with Vsock, so this communication is not visible from workloads, so kata-agent and containers can safely share the host network namespace. In our case, agent protocol communication as well as other network activities become visible to workload, if we share a network namespace with kata-agent and workload.
The old peer pod implementation, kata-agent used abstract Unix domain socket to communicate with agent-protocol-forwarder. Abstract Unix domain sockets are isolated with network namespaces, so the abstract Unix domain socket for agent protocol was visible to work loads when we ran kata-agent in in podns. To avoid this, I changed to run kata-agent in the host network namespace.
After https://github.com/confidential-containers/cloud-api-adaptor/pull/204 was merged, kata-agent uses a normal Unix domain socket, which is isolated with mount namespaces, not network namespaces, so we don't need to care about the issue of abstract Unix domain sockets.
Another reason to run use separated network namespaces between kata-agent and containers is image pulls. In the usual set up of containerd and crio, images are pulled in the network of worker nodes, not Kubernetes pod network configured by CNI plugins. There are differences between two networks in general such as reachable IP addresses and used DNS servers. To make consistent with this behavior, kata-agent is runs on the host network, which is not a Kubernetes network, while containers run on the podns network namespace, which belongs to a Kubernetes pod network.
I am wondering it is OK to launch attestation-agent implicitly in the network namespace of workload.  Does it cause conflicts with workload that explicit uses ports 50000 and 50001? I think Unix domain sockets are a safer option to avoid such conflicts.
BTW, ports 50000 and 50001 are in the range of Linux's ephemeral ports (32768–60999), so attestation-agent may fail to start if other processes have already used the ports unintentionally.

Forgot that we will not always have attestation-agent present on the podvm (depending on the AA_KBC setting), we need to also add the unit conditionally.

I think launching another attestation agent in the podns namespace is OK, but I come up with anther idea using socat port forwarding, if launching two attestation agents is considered redundant from the perspective of resource usages.
The following command establishes port forwarding between the two network namespaces. We need to install socat, but can avoid redundant attestation agent processes.
ip netns exec podns socat tcp-listen:50001,bind=<IP_ADDRESS>,reuseaddr,fork /tmp/aa.sock &
socat unix-listen:/tmp/aa.sock,fork tcp-connect:<IP_ADDRESS>:50001 &

https://serverfault.com/a/1117799

Forgot that we will not always have attestation-agent present on the podvm (depending on the AA_KBC setting), we need to also add the unit conditionally

Resorted to creating unit-enabling the symlink in podvm/Makefile.inc now (and adding it to .gitignore)

I think launching another attestation agent in the podns namespace is OK, but I come up with anther idea using socat port forwarding, if launching two attestation agents is considered redundant from the perspective of resource usages.
The following command establishes port forwarding between the two network namespaces. We need to install socat, but can avoid redundant attestation agent processes.
ip netns exec podns socat tcp-listen:50001,bind=<IP_ADDRESS>,reuseaddr,fork /tmp/aa.sock &
socat unix-listen:/tmp/aa.sock,fork tcp-connect:<IP_ADDRESS>:50001 &

https://serverfault.com/a/1117799

So circumventing the network ns isolation by rerouting through a domain socket. that works I guess. Could also be facilitated in a unit. What do others think?

ATM I cannot build the image with AA it fails on obscure Makefile error which I couldn't figure out what went wrong with it:
$ cd azure/image/
$ make clean
rm -f "podvm-106100f-amd64" "" /tmp/tmp.zJH65dzGku/cloud-api-adaptor/podvm/files/usr/local/bin/agent-protocol-forwarder /tmp/tmp.zJH65dzGku/cloud-api-adaptor/podvm/files/usr/local/bin/kata-agent /tmp/tmp.zJH65dzGku/cloud-api-adaptor/podvm/files/pause_bundle/rootfs/pause
rm -fr "skopeo" "umoci" "pause" "/tmp/tmp.zJH65dzGku/cloud-api-adaptor/podvm/files/pause_bundle"

But when I set the env var:
$ export AA_KBC=cc_kbc
$ make clean
../../podvm/Makefile.inc:62: *** missing separator.  Stop.

I think launching another attestation agent in the podns namespace is OK, but I come up with anther idea using socat port forwarding, if launching two attestation agents is considered redundant from the perspective of resource usages.
The following command establishes port forwarding between the two network namespaces. We need to install socat, but can avoid redundant attestation agent processes.
ip netns exec podns socat tcp-listen:50001,bind=<IP_ADDRESS>,reuseaddr,fork /tmp/aa.sock &
socat unix-listen:/tmp/aa.sock,fork tcp-connect:<IP_ADDRESS>:50001 &

https://serverfault.com/a/1117799

So circumventing the network ns isolation by rerouting through a domain socket. that works I guess. Could also be facilitated in a unit. What do others think?

Seems ok. One (repeat) question I have is on using different KBCs with the same attestation agent. Like using offline_kbc_fs to get the container registry auth secrets for image-rs and vTPM to get the application secrets.
In the earlier discussion you had mentioned about selecting the kbc implementation using the KbcName param in the GetResourceRequest call.  Do you know how will image-rs use offline_kbc_fs ? Any specific settings needed ?

One (repeat) question I have is on using different KBCs with the same attestation agent. Like using offline_kbc_fs to get the container registry auth secrets for image-rs and vTPM to get the application secrets. In the earlier discussion you had mentioned about selecting the kbc implementation using the KbcName param in the GetResourceRequest call. Do you know how will image-rs use offline_kbc_fs ? Any specific settings needed ?

I have to test this, but my high-level understanding is that the image decryption API  accepts a simple byte encoded input, which is then parsed. The parsed input_payload should contain the KBC name. So image-rs would need to set it when calling the AA endpoint. Which KBC's are included in AA is defined at build-time per feature toggle.
https://github.com/confidential-containers/attestation-agent/blob/main/app/src/rpc/keyprovider/mod.rs#LL78C1-L83C18

@mkulke I haven't seen such situation, so I checked the socat doc, and found some related options.
I think we can control concurrent connections by adding thebacklog and max-children options to the workload-side socat.
http://www.dest-unreach.org/socat/doc/socat.html#GROUP_LISTEN
max-children limits the number of established connections to the next socat, and backlog limits the number of incoming connections that can wait before accept is called.
ip netns exec podns socat tcp-listen:50001,bind=<IP_ADDRESS>,reuseaddr,fork,backlog=0,max-children=1 /tmp/aa.sock &

For example, with the above options, at most only two connections can be in established states; one for connection to actual attestation agent, and another one in backlog. Additional connections will not be accepted, and will be in SYN-SENT in the workload side.

@mkulke I haven't seen such situation, so I checked the socat doc, and found some related options.
I think we can control concurrent connections by adding thebacklog and max-children options to the workload-side socat. http://www.dest-unreach.org/socat/doc/socat.html#GROUP_LISTEN
max-children limits the number of established connections to the next socat, and backlog limits the number of incoming connections that can wait before accept is called.
ip netns exec podns socat tcp-listen:50001,bind=<IP_ADDRESS>,reuseaddr,fork,backlog=0,max-children=1 /tmp/aa.sock &

For example, with the above options, at most only two connections can be in established states; one for connection to actual attestation agent, and another one in backlog. Additional connections will not be accepted, and will be in SYN-SENT in the workload side.

Thanks for looking into it @yoheiueda I was wondering what reasonable defaults are. I find it hard to anticipate those things. I could imagine a threaded workloads that maintain a pool of open connections to a gRPC server (maybe implicitly by some default keepalive option in a middleware/library) and that would lead to unintuitive errors.
2 concurrent connections might be too rigid, we can start maybe with 10 and document the behaviour for the time being. The whole AA story is still a bit in flux, so we might not need to come up with something super solid.

@mkulke

2 concurrent connections might be too rigid, we can start maybe with 10 and document the behaviour for the time being. The whole AA story is still a bit in flux, so we might not need to come up with something super solid.

2 was just an example, and I think 10 is a good value for now. We will adjust it when we encounter some issues.

In todays community call there was a shared sentiment to go with the second attestation-agent process for the time being and revise the architecture later in a non-breaking fashion, possibly by extending AA to listen on multiple sockets and isolate the pod <=> attestation-agent traffic.


Google search console mobile, 'content wider than screen'

Hi,
I am getting a report from google that some of my site content is too wide for mobile screens.
I think I have narrowed this down to my code snippets where I use back ticks and language marker to give a <code> rendering. It appear the text does not wrap at all.
I have found that using the backtick causes the site to create a <pre> block around the code snippet.
And from this link on stack overflow here. The issue appear to be the <pre>
I am not sure how to solve this. Does anyone have any suggestions?
Example pages:
https://bas-man.github.io/cheatsheets/git/snippets/change-commit-date/
https://bas-man.github.io/cheatsheets/python/snippets/padding-numbers/

Hey, @Bas-Man Thanks for bringing this to our attention. We'll check it out.


fix: assets release using oclif

Description
Update oclif dependencies to benefit from https://github.com/oclif/oclif/pull/987 which is missing from souvikns-oclif leading to permissions errors.
Details

use official oclif npm package instead of souvikns-oclif
bump versions of oclif dependencies
update syntax for oclif pack commands

Related issue(s)

Fixes #425

Thanks for the PR @CyberHippo. Can you please have a look at the conflicts you have there, and also failing tests.
Also, one more small stuff, please do not update CLI version in package files, these happen automatically on release

@derberg I fixed the conflicts and removed the version bump. The tests are passing locally. I did not upgrade @oclif/core to v2 since it was not necessary and above my Typescript skills.

Tests are failing https://github.com/asyncapi/cli/actions/runs/4607360398/jobs/8146614119
not because of tests but because there is an issue with npm install. I remember we had it in the past and it was fixed only because there were some other merges related to package-json that solved the problem. We do not know what fixed it.
My only idea is:

remove package-lock
take 1:1 what is in https://github.com/asyncapi/cli/blob/master/package-lock.json
run npm install --verbose

🤞🏼

@derberg I suspect that the tests are failing because I generated a package-lock.json using npm >= 7 which is now creating a v2 lockfile. The current Github Actions are using Node 14 as a runtime which ships npm < 7 and use v1 lockfiles.
# From the "PR testing - if Node project" workflow logs
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

Since Node 14 will be EOL on the 2023-04-30 I added an additional commit to update the runtime of current Github Actions to Node 18. I think that this may be best for the stability of the workflows.
I could also regenerate a package-lock.json using npm < 7 which hopefully will fix the failing installation during the tests. Or regenerate the lock using the lock from the master branch as suggested. Let me know what you think is best.
I noticed in the "PR testing - if Node project" workflow logs that the previous stage Install dependencies is failing silently :
[...]
npm http fetch GET 200<EMAIL_ADDRESS>2020ms
npm timing stage:rollbackFailedOptional Completed in 1ms
npm timing stage:runTopLevelLifecycles Completed in 10217ms
npm verb stack Error: Unsupported platform for<EMAIL_ADDRESS>wanted {"name":"@swc/core-android-arm-eabi","version":"1.3.9","engines":{"node":">=10"},"cpu":["arm"],"os":["android"],"dependencies":{"@swc/wasm":"1.2.122"},"optionalDependencies":{},"peerDependenciesMeta":{},"devDependencies":{},"bundleDependencies":false,"peerDependencies":{},"deprecated":false,"_resolved":"https://registry.npmjs.org/@swc/core-android-arm-eabi/-/core-android-arm-eabi-1.3.9.tgz","_integrity":"sha512-+F+sU2l49Po4tJoNtIpFwt0k1sspymvPMM+DCpnkHF1idzRiOU5NGgVzmLDjoO9AnxHa7EBJ3itN+PP2Dd06+A==","_shasum":"6ab77525f2d22fcd321d0e29704d0820608b9e18","_shrinkwrap":null,"_id":"@swc/core-android-arm-eabi@1.3.9","_from":"@swc/core-android-arm-eabi@1.3.9","_requested":{"type":"version","registry":true,"raw":"@swc/core-android-arm-eabi@1.3.9","name":"@swc/core-android-arm-eabi","escapedName":"@swc%2fcore-android-arm-eabi","scope":"@swc","rawSpec":"1.3.9","saveSpec":null,"fetchSpec":"1.3.9"},"_spec":"@swc/core-android-arm-eabi@1.3.9","_where":"/home/runner/work/cli/cli/node_modules/@swc/core"} (current: {"os":"linux","cpu":"x64"})
npm verb stack     at checkPlatform (/opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/node_modules/npm-install-checks/index.js:46:14)
npm verb stack     at thenWarnEngineIssues (/opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/lib/install/validate-args.js:63:5)
npm verb stack     at /opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/node_modules/iferr/iferr.js:3:64
npm verb stack     at checkEngine (/opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/node_modules/npm-install-checks/index.js:25:10)
npm verb stack     at module.exports.isInstallable (/opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/lib/install/validate-args.js:60:3)
npm verb stack     at resolveWithNewModule (/opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/lib/install/deps.js:677:10)
npm verb stack     at /opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/lib/install/deps.js:600:7
npm verb stack     at /opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/node_modules/iferr/iferr.js:3:64
npm verb stack     at /opt/hostedtoolcache/node/14.21.3/x64/lib/node_modules/npm/node_modules/call-limit/call-limit.js:28:43
npm verb stack     at processTicksAndRejections (internal/process/task_queues.js:77:11)
npm verb pkgid<EMAIL_ADDRESS>npm verb cwd /home/runner/work/cli/cli
npm verb Linux 5.15.0-1034-azure
npm verb argv "/opt/hostedtoolcache/node/14.21.3/x64/bin/node" "/opt/hostedtoolcache/node/14.21.3/x64/bin/npm" "install" "--loglevel" "verbose"
npm verb node v14.21.3
npm verb npm  v6.14.18
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"android","arch":"arm"} (current: {"os":"linux","arch":"x64"})
npm ERR! notsup Valid OS:    android
npm ERR! notsup Valid Arch:  arm
npm ERR! notsup Actual OS:   linux
npm ERR! notsup Actual Arch: x64
npm verb exit [ 1, true ]
npm timing npm Completed in 11659ms

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2023-04-04T15_20_08_670Z-debug.log
Error: Process completed with exit code 1.

@derberg My bad, I went too fast finding and replacing deprecated workflows. I reverted the changes to the centrally managed workflows. Should I wait for https://github.com/asyncapi/.github/pull/226 to be merged since the failing workflow is centrally managed and keep the v2 lockfile ?

we might do the trick that you change here this one global pr testing workflow to enable this PR to be merge. And once my PR is merged, all will be set back to track

this is the most important PR we are waiting for https://github.com/asyncapi/.github/pull/187

@derberg I just updated the global PR testing workflow to run on Node 18 again. Let's see if the installation error persists.

@Souvikns yes they will, but it is not a problem as we are now doing some stuff with global workflows anyway, and these will "overwrite" but not change stuff. What I mean is that what @CyberHippo changed is be replaced by "the same" but coming from global, later in a week or two.

/rtm

@allcontributors please add @CyberHippo for code,infra

not yet released because of https://github.com/asyncapi/cli/pull/514

@CyberHippo I think it did not work in case of macos. So pipelines are now green but macos distro pipeline shows below when trying to upload to GH release:
🤔 Pattern 'dist/macos/asyncapi.pkg' does not match any files.
🤔 dist/macos/asyncapi.pkg not include valid file.

not sure if something changes with generated package name an scripts/releasePackagesRename.js no longer works 🤔
you mind having a look?

all the rest for linux is here https://github.com/asyncapi/cli/releases/tag/v0.37.2


[Q] Getting launch agent error while deploying experiment to kubernetes . Previously it was running fine . Noticed that the helm chart image got changed

Hi ,
I had a working WandB launch queue and agent configured . Today I updated the kubernetes config to include a Pod Disruption budget for the WandB jobs . During this process the agent helm chart was also ran , and I saw that the image is updated from [0.16.0-state-fix] to [0.16.3] . After this I ran a pipeline to enque a demo experiment to check everything is fine , but it is crashing due to agent issues . From the agent logs I can see:
wandb: ERROR launch: Error running job: Exception when ensuring Kubernetes API key secret: Server disconnected
I have a valid API key . The same key was used to enque the jobs , create queues and also in the agent config .
What has changed ?

This is the stack trace :
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/wandb/sdk/launch/runner/kubernetes_runner.py", line 678, in ensure_api_key_secret
return await core_api.create_namespaced_secret(namespace, secret)
File "/usr/local/lib/python3.9/site-packages/kubernetes_asyncio/client/api_client.py", line 185, in __call_api
response_data = await self.request(
File "/usr/local/lib/python3.9/site-packages/kubernetes_asyncio/client/rest.py", line 238, in POST
return (await self.request("POST", url,
File "/usr/local/lib/python3.9/site-packages/kubernetes_asyncio/client/rest.py", line 185, in request
r = await self.pool_manager.request(**args)
File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 605, in _request
await resp.start(conn)
File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 966, in start
message, payload = await protocol.read()  # type: ignore[union-attr]
File "/usr/local/lib/python3.9/site-packages/aiohttp/streams.py", line 622, in read
await self._waiter
aiohttp.client_exceptions.ServerDisconnectedError: Server disconnected
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/wandb/sdk/launch/agent/agent.py", line 604, in task_run_job
await self._task_run_job(
File "/usr/local/lib/python3.9/site-packages/wandb/sdk/launch/agent/agent.py", line 673, in _task_run_job
run = await backend.run(project, image_uri)
File "/usr/local/lib/python3.9/site-packages/wandb/sdk/launch/runner/kubernetes_runner.py", line 587, in run
job, secret = await self._inject_defaults(
File "/usr/local/lib/python3.9/site-packages/wandb/sdk/launch/runner/kubernetes_runner.py", line 424, in _inject_defaults
api_key_secret = await ensure_api_key_secret(
File "/usr/local/lib/python3.9/site-packages/wandb/sdk/launch/runner/kubernetes_runner.py", line 704, in ensure_api_key_secret
raise LaunchError(
wandb.sdk.launch.errors.LaunchError: Exception when ensuring Kubernetes API key secret: Server disconnected

Hi @abindg there were 2 recent changes that could impact you here. First, we updated the helm chart to include the release name in the service account, secrets and many other objects: https://github.com/wandb/helm-charts/pull/47/files. If you have specific perms associated with the old service account name this could be the source of the issue.
This PR: https://github.com/wandb/wandb/pull/6722  also aims to create the W&B api key secret for each pod.  This is the source of your exact error. It is unclear why your api server is disconnecting, if you have access to the api server logs that would be quite helpful for debugging.

Hi @abindg there were 2 recent changes that could impact you here. First, we updated the helm chart to include the release name in the service account, secrets and many other objects: https://github.com/wandb/helm-charts/pull/47/files. If you have specific perms associated with the old service account name this could be the source of the issue.
This PR: #6722 also aims to create the W&B api key secret for each pod. This is the source of your exact error. It is unclear why your api server is disconnecting, if you have access to the api server logs that would be quite helpful for debugging.

I have removed the cluster Role binding and only using Role binding for my setup . The role binding binds the role to the service account
With the exact same configs using the older image everything works
I have checked the secret , checked the API key from the secret , it is the same as that supplied . The agent logs only show this details that I have pasted

hi @KyleGoyette
I had substituted the rbac.yaml of helm template with my own rbac.yaml . It looks like below and removes cluster role and custer role binding .

apiVersion: v1
kind: ServiceAccount
metadata:
name: wandb-launch-serviceaccount-{{ .Release.Name }}
namespace: {{ .Values.namespace }}
{{- if .Values.serviceAccount.annotations }}
annotations:
{{- toYaml .Values.serviceAccount.annotations | nindent 4 }}
{{- end }}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: {{ .Values.namespace }}
name: wandb-launch-agent-{{ .Release.Name }}
rules:

apiGroups: [""]
resources: ["pods", "configmaps", "secrets", "pods/log"]
verbs: ["create", "get", "watch", "list", "update", "delete", "patch"]
apiGroups: ["batch"]
resources: ["jobs", "jobs/status"]
verbs: ["create", "get", "watch", "list", "update", "delete", "patch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: wandb-launch-role-binding-{{ .Release.Name }}
namespace: {{ .Values.namespace }}
subjects:

kind: ServiceAccount
name: wandb-launch-serviceaccount-{{ .Release.Name }}
namespace: {{ .Values.namespace }}
roleRef:
kind: Role
name: wandb-launch-agent-{{ .Release.Name }}
apiGroup: rbac.authorization.k8s.io

Okay, I'd like to try to isolate the issue to either the new helm chart or the new agent code. Can you try installing the newest version of the helm chart, but update the image to:
wandb/launch-agent:0.16.0-state-fix?

WandB Internal User commented:
KyleGoyette commented:
Hi @abindg there were 2 recent changes that could impact you here. First, we updated the helm chart to include the release name in the service account, secrets and many other objects: https://github.com/wandb/helm-charts/pull/47/files. If you have specific perms associated with the old service account name this could be the source of the issue.
This PR: https://github.com/wandb/wandb/pull/6722  also aims to create the W&B api key secret for each pod.  This is the source of your exact error. It is unclear why your api server is disconnecting, if you have access to the api server logs that would be quite helpful for debugging.

Hi @abindg, I wanted to check if you had the chance to test what Kyle suggested:

Can you try installing the newest version of the helm chart, but update the image to:
wandb/launch-agent:0.16.0-state-fix?


Setting: Sunlight Arrows in OOT

Title is self-explanatory. Add an option for Light Arrows to activate Sun Switches. This would make LAs functionally in parity with MM as well as the Mirror Shields effectively (each Mirror Shield locking only 1 check lol). Since it's a setting like Blue Fire Arrows, it can be optionally turned on/off. The logic for this would be fun, especially in seeds where OOT Mirror locks LAs or LAs locks OOT Mirror in Spirit Temple.

Done in 7a51d4c


Usage with bower

I am trying to include the side navbar in a project I am working on. I am using Laravel 5.3 and with the help of Elixir / Gulp I compile some SASS files to CSS. On of my SASS files includes the following:
@import "bower_components/bootstrap-sass/assets/stylesheets/bootstrap";
@import "bower_components/bootstrap-side-navbar/source/assets/stylesheets/navbar-fixed-side.scss";

However, compilation fails:
Error: File to import not found or unreadable: bootstrap/variables
       Parent style sheet: /home/vagrant/www/office.thetravelspy.dev/bower_components/bootstrap-side-navbar/source/assets/stylesheets/navbar-fixed-side.scss
        on line 1 of bower_components/bootstrap-side-navbar/source/assets/stylesheets/navbar-fixed-side.scss
>> @import 'bootstrap/variables';

Apparently the file bootstrap/variables isn't found. I have been fiddling around with settings include paths and such, but that does not make any difference. Am I doing something wrong or isn't this just not going to work?
Thanks!

I haven't actually used Bower. Have you tried simply removing the line @import 'bootstrap/variables';? If you're importing the whole of Bootstrap then the variables should already be imported I think.

the dropdown inside navigation is by default open. even not togling. any sugesstion or solution..? Thanks

I have indeed tried that and that "fixes" the issue for me. But, then the whole point of Bower is missed: to install a package and get things working without having to hack code :smile:
It is working for me now, as I have made a local copy of the source SASS of this package in my versioning system. But I think that is not the way to go.
Why is the @import line present in the code? It is required to make things work on other systems?

Bower support was added through https://github.com/samrayner/bootstrap-side-navbar/pull/4 so I assume it worked for @HarelM? As I say, I haven't used Bower.
Personally I think having this as a Bower package is of very little benefit as the repo consists of a single stylesheet. I don't have any plans to make regular updates to the stylesheet and it's unlikely that it will break due to Bootstrap 3 changes as the team are focused on Bootstrap 4. I might re-write a side nav for Bootstrap 4 when that is released but it would be a separate project.
I think copying the scss file into your project is the way to go.

Using bower allows updates to be pushed automatically for all the repositories you are using, I can't see how one can work without it (or an equivalent versioning system to all 3rd party dependencies), but that's just me.
It did work for me when I used it but I needed only the css file and not the scss file, BTW if you need something else you can override the bower "main" property for certain repositories.
I needed a toggle-able side bar so I moved to another project, feel free to update the bower.json file to your needs.

All right. Maybe I'll just fork this repo and create a version that suits me. Thanks!


[Enhancement] Add way to explicitly show/hide special workspace (rather than 'toggle')

The Problem
The dispatcher togglespecialworkspace has no (documented) way of always-showing, or always-hiding, a workspace. It can only toggle the visibility between shown/hidden.
I am looking for a method with this behaviour:

If the given special workspace is hidden, then show it
Else do nothing (the given special workspace is already shown)

...and the inversely to hide it.
Possible Solution 1
The dispatcher togglespecialworkspace could take an optional second parameter for the desired action (toggle, show, or hide). I believe this is compatible with the current API.
# Default: `toggle`
hyprctl dispatch togglespecialworkspace magic
hyprctl dispatch togglespecialworkspace magic, toggle
# New behaviour
hyprctl dispatch togglespecialworkspace magic, show
hyprctl dispatch togglespecialworkspace magic, hide

Possible Solution 2
Alternatively, two new dispatchers could be introduced. I would imagine this is less favorable as it increases the amount of dispatchers.
hyprctl dispatch hidespecialworkspace magic
hyprctl dispatch showspecialworkspace magic

Possible Solution 3
Another alternative could be a way to request the visibility state of a specific special workspace. If this is already possible, I could not find a way to do it.
Maybe hyprctl workspaces could list a visible: 0/1 value for special workspaces?
hyprctl workspaces -j | jq '.[] | select(.name == "special:<NAME>") | .visible'
# Prints `0` or `1` (or nothing, if `<NAME>` is not the name of a special workspace)

hyprctl activeworkspace never returns the name of a special workspace, even if a special workspace is active and focused. Is this intended behviour? If not, I will open a new issue for that.
Current Workaround
To hide the current special workspace (and hence hide all special workspaces), the user can show, and immediately hide, a non-existent empty special workspace (named __TEMP here).
hyprctl dispatch togglespecialworkspace __TEMP
hyprctl dispatch togglespecialworkspace __TEMP

To show a special workspace: hide all special workspaces (as shown above), and then toggle the desired workspace.
hyprctl dispatch togglespecialworkspace __TEMP
hyprctl dispatch togglespecialworkspace __TEMP
hyprctl dispatch togglespecialworkspace <NAME>

Possibly related: #7662

https://github.com/hyprwm/Hyprland/pull/6862

#6862

I did not see this! Thanks!
I will still keep this issue open until the PR is merged, as it provides alternative solutions and more context.


Remove NJ from API Information

Problem statement
NJ no longer requires additional steps to send data through ReportStream. They need to be removed from the Getting Started page.
What you need to know

Content request ticket located here: #11284

Current page link: https://reportstream.cdc.gov/resources/api/getting-started

Change requested: Remove New Jersey from this portion on both PDF and website: Private Zenhub Image

Updated PDF with New Jersey removed located here: pdf file here

Acceptance criteria

[x] New Jersey removed from Getting Started Page per above
[ ] "Downloadable PDF" link on https://reportstream.cdc.gov/resources/api will download (NOT OPEN/LINK) the new updated PDF
[x] Edit "last updated" date on the Getting Started page to be the date that this change deploys

Hey team! Please add your planning poker estimate with Zenhub @etanb @jpandersen87 @penny-lischer

@audreykwr  I need permission for the pdf


STEPS need to be added for SUSE distro in addition to make current steps clearer

[There needs to be clear steps for SUSE distribution
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-test-latency
for SUSE
sudo zypper install gcc -y -q
sudo zypper install git -y -q
sudo zypper install gcc-c++ -y
sudo zypper install ncurses-devel -y
sudo zypper install -y automake
sudo zypper install -y autoconf

SLES SAP15 gives the error message below:
error message at ./autogen.sh
SLES15SAP:~/sockperf # ./autogen.sh
++ pwd

oldpwd=/root/sockperf
++ dirname ./autogen.sh
topdir=.
cd .
CURRENT_VERSION_FILE=./build/current-version
. ./build/versioning.sh
+++ cat version
+++ tr -d '\n'
++ VERSION=3.8
+++ git rev-parse HEAD
++ GIT_REF=31ee322aa82abc26a55e5adb608dcdbca3f3d028
+++ git describe --long --abbrev=12 --dirty
++ x=3.8-0-g31ee322aa82a
++ '[' -n 3.8-0-g31ee322aa82a ']'
+++ echo 3.8-0-g31ee322aa82a
+++ sed -e s/-g/.git/ -e s/-dirty/.dirty/
+++ sed 's/.*-//'
++ x=0.git31ee322aa82a
++ RELEASE=0.git31ee322aa82a
echo 3.8-0.git31ee322aa82a
echo 31ee322aa82abc26a55e5adb608dcdbca3f3d028
rm -rf autom4te.cache
mkdir -p config/m4 config/aux
autoreconf -v --install
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I config/m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
configure.ac:70: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
exit 1

This is mitigated once libtool is installed
sudo zypper install libtool

make command not recognized. to mitigated had to install make
sudo zypper install make

the instructions suggest that running make is all that is needed since it mentions "make install" is faster but you need to run both commands. this is not very intuitive and it would be better if that was stated clearer for the customer.
   sudo make
   sudo make install

]

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

ID: 96a8a8ae-019a-9164-7506-e6a2ac60269c
Version Independent ID: 1ba5d5b9-ca37-ba98-6866-4cf726ad1172
Content: Test Azure virtual machine network latency in an Azure virtual network
Content Source: articles/virtual-network/virtual-network-test-latency.md
Service: virtual-network
GitHub Login: @steveesp
Microsoft Alias: steveesp

@frpierre  we'll review your feedback and get back to you shortly. Thanks.

Thank you for your feedback! We have assigned this issue to the author to review further and take the next course of action.


Grafana correction in caliper documentation

Checklist

1437  A link to the issue/user story that the pull request relates to
[ ]  How to recreate the problem without the fix
[ ]  Design of the fix
[ ]  How to prove that the fix works
[ ]  Automated tests that prove the fix keeps on working
[ ]  Documentation - any JSDoc, website, or Stackoverflow answers?

Issue/User story

Steps to Reproduce

Existing issues

[ ] Stack Overflow issues
[ ] GitHub Issues
[ ] Discord history

Design of the fix

Validation of the fix

Automated Tests

What documentation has been provided for this pull request

@aklenik can you review this?


can't install grpcio==1.47.5

python version:3.10 or 3.11
pip version: 23.0.1
system: mac
pip install grpcio==1.47.5
Could not find <Python.h>. This could mean the following:
* You're on Ubuntu and haven't run apt-get install python3-dev.

Similar issue here Using Macbook 2.6 Intel. Ventura 13.2.1
I end it up moving to another Mackbook M1. :(
Some fix I found that for other users fix the issue:
This seems to work well, do the following in the terminal

export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1
export GRPC_PYTHON_BUILD_SYSTEM_ZLIB=1
And then install whatever package that you wanted to install, in my case I was trying to install firebase admin and I had to run the following

pip install firebase-admin
Or just run the below command if you just want to install grpcio

pip install grpcio

this thread helpful to understand this issue in detail https://github.com/grpc/grpc/issues/25082

The error message you are receiving suggests that the Python development headers are not installed on your system. The grpcio package requires these headers in order to compile its native extensions.
If you have already tried the suggested solutions in the error message and are still having trouble, you may want to consider using a different version of Python that is known to be compatible with grpcio.
However, before switching to a different version of Python, you may want to try installing the grpcio package using a package manager other than pip, such as conda or homebrew. These package managers may be able to resolve dependencies and install the necessary development headers automatically.
If you do decide to switch to a different version of Python, be sure to check the compatibility of any other packages you are using with the new version before making the switch. Additionally, it may be helpful to create a virtual environment for your project to isolate it from any system-level changes you make.

You have to use python3.10

You have to use python3.10

yes，previous python version = 3.10.0, now update to 3.10.10 ,everything is fine

The error message you are receiving suggests that the Python development headers are not installed on your system. The grpcio package requires these headers in order to compile its native extensions.
If you have already tried the suggested solutions in the error message and are still having trouble, you may want to consider using a different version of Python that is known to be compatible with grpcio.
However, before switching to a different version of Python, you may want to try installing the grpcio package using a package manager other than pip, such as conda or homebrew. These package managers may be able to resolve dependencies and install the necessary development headers automatically.
If you do decide to switch to a different version of Python, be sure to check the compatibility of any other packages you are using with the new version before making the switch. Additionally, it may be helpful to create a virtual environment for your project to isolate it from any system-level changes you make.

thx a lot, conda's python version=3.10.10,all dependencies can be down in this version. so i checked my python and found that is 3.10.0.when i update to 3.10.10, everything is ok


Consider implementing RegEx type, methods, and literal

Would be useful for Wordle input validation.
Remember to document.

Duplicates #239


KOGITO-5975  Public API: MapDataContext#get(String,Class) returns null

The method is present but erroneously stubbed (returned null: discovered this while working on examples)
It should pull the data from the map and then return a value of that type (performing a conversion -- not a cast -- if necessary)
e.g.:

        User u = new User();
        u.firstName = "Paul";
        u.lastName = "McCartney";
        u.addr = new Address();
        u.addr.street = "Abbey Rd.";

        MapDataContext mdc = MapDataContext.of(Map.of("Paul", u));
        User paul = (User) mdc.get("Paul"); // returns Object
        User user = mdc.get("Paul", User.class); // returns User

How to retest this PR or trigger a specific build:

Run all builds
Please add comment: Jenkins retest this

Run (or rerun) specific test(s)
Please add comment: Jenkins (re)run [runtimes|optaplanner|apps|examples] tests

Quarkus LTS checks
Please add comment: Jenkins run LTS

Run (or rerun) LTS specific test(s)
Please add comment: Jenkins (re)run [runtimes|optaplanner|apps|examples] LTS

Native checks
Please add comment: Jenkins run native

Run (or rerun) native specific test(s)
Please add comment: Jenkins (re)run [runtimes|optaplanner|apps|examples] native

Full Kogito testing (with cloud images and operator BDD testing)
Please add comment: Jenkins run BDD
This check should be used only if a big change is done as it takes time to run, need resources and one full BDD tests check can be done at a time ...

The (build) Runtimes check has failed. Please check the logs.

The (build) Examples check has failed. Please check the logs.

Jenkins run examples tests

Jenkins run runtimes tests

The (build) Runtimes check has failed. Please check the logs.

The (build) Examples check has failed. Please check the logs.


Title menu logo doesn't work properly in 1.19.4

Need I say more?

Had a thought, the launcher I use (Prism Launcher) doesn't seem to check the resource pack version properly, meaning that I'd be getting the latest release to modrinth, rather then latest for that game version. Do you mind checking the latest resourcepack version and seeing if that produces the same result as I got?

Yep, good to know. Will change version now


Drawer Open detection

Version
Tell us which versions you are using:

react-native-router-flux v4.?.? (v3 is not supported)
react-native v0.?.?

I have a Custom NavBar so my drawer button doesnt work.
But on my Iphone device i can just swipe right to open the drawer which is fine.
But i cannot detect if the drawer is open using onEnter or onOpen

It looks like question for stackoverflow. You can try to check this.props.navigation.state


MM-35721: Clicking an Avatar should open Profile Popover

Summary
Clicking an avatar in thread item will open profile popover on

the root post in the center channel
the global threads page

Ticket Link
Jira ticket: https://mattermost.atlassian.net/browse/MM-35721
Fixes https://github.com/mattermost/mattermost-server/issues/19348
Screenshots
before
https://user-images.githubusercontent.com/37421564/153732631-8c993b1a-6c05-44eb-814d-d6838511752e.mov
after
https://user-images.githubusercontent.com/37421564/153732637-76a4ebfa-3716-40e7-ad8c-4ff0416e78a2.mov
Release Note
NONE

Hello @sinansonmez,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Adding @furqanmlk as this PR also has an E2E test

/e2e-test

Triggering e2e testing with options:
<nil>

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/150985

Thanks for the feedback @jgilliam17, please see my comments below,

Cypress test case is failing, See report
I also created a Zephyr test case and added the test id. See suggestion.

The tests were passing in my local but I will check the report to fix them

2. Tooltip with user name is missing; tooltip is present when hovering over + icon. Also avatars should be slightly overlapping etc.

For tooltip,

I kept the tooltip if avatars are grouped together in single avatar

I removed it intentionally for single avatar, to keep the same behaviour as message. In the screenshot below, when you hover purple profile image, you don't see tooltip for username but you click to open a profile popover. Please let me know if you would like to keep both username tooltip on hover and profile popover for single avatar
I will fix overlapping issue.

3. On global threads, clicking on the avatar also opens that thread in the thread view.  @matthewbirtch should we suppress thread open on avatar click?
We are currently not suppressing thread open on avatar click on global threads, but do so on main channel view thread avatars

On global threads, the page opens with empty thread view (red part in the screenshot) to show all replies. Since the thread view is already there, showing profile popover and opening the thread could be useful with a single click on avatar

Please let me know about final decision @matthewbirtch

I removed it intentionally for single avatar, to keep the same behaviour as message. In the screenshot below, when you hover purple profile image, you don't see tooltip for username but you click to open a profile popover. Please let me know if you would like to keep both username tooltip on hover and profile popover for single avatar

Please keep the tooltip when hovering over individual avatars in the thread footer

We are currently not suppressing thread open on avatar click on global threads, but do so on main channel view thread avatars
On global threads, the page opens with empty thread view (red part in the screenshot) to show all replies. Since the thread view is already there, showing profile popover and opening the thread could be useful with a single click on avatar

Please let me know about final decision @matthewbirtch

I think it's fair to assume that if a user clicks an avatar that they aren't intending to open the thread, so I would suppress opening the thread in this case and only open the profile popover

/e2e-test

You don't have permissions to trigger this command.
It's only available for organization members.

Triggering e2e testing with options:
<nil>

Thanks to you and other reviewers for the support @Willyfrog


Update fromEvent documentation

Add information about handling events with more than one argument.

Does this concern only EventEmitter events?

Yeah.  most.fromEvent supports both EventTarget and EventEmitter.  However, only EventEmitter events can be multi-valued.  EventTarget is always single-valued, since EventListener is always single-valued (See the whatwg spec for EventTarget and EventListener)

Ok. I've added another commit reflecting your  suggestions.

Looks great, @jfedyczak.  Thank you!


#20 implement coroutines example

Added the test dependencies for coroutines. Also, was necessary to cr…eate a rule for dispatchers. A minor update at resource class. For cleaner purpose, I added a BaseViewModel for the DispatcherProvider, and avoid memory leak

There are some options about how we can implement kotlin coroutines.

Creating a different branch for implementation.
In the near future, I want to add a bottom nav bar with two fragments. One of them is an example for RxJava implementation and the other one for coroutines.

because of those reasons, it is so early to merge this PR, so I want to hold this PR for small amount of time.


DRILL-7839: Update the doc and remove the formatter file on gh-pages branch

DRILL-7839: Update the doc and remove the formatter file on gh-pages branch
Description
IntelliJ IDEA and Eclipse formatter file download should be unified. See also DRILL-7837
Documentation
See also _docs/developer-information/contribute-to-drill/010-apache-drill-contribution-guidelines.md
Testing
(Please describe how this PR has been tested.)

@luocooong, since @cgivre has merged your PR I applied the rewording in a subsequent commit (39e8627) and you don't need to worry about it.

@luocooong, since @cgivre has merged your PR I applied the rewording in a subsequent commit (39e8627) and you don't need to worry about it.


[3.x] Fix Linux cross-bits compilation non-x86

When making a 32 bits build from 64 machine (and vice versa) the built system assumed x86 (forcing -m32 or -m64).
This commit backports the arch detection function from 4.x and only use it in the X11 platform to avoid adding the incorrect flags.
I believe that unlike the whole "arch" refactor, this change is more likely to be backported to 3.5, so we can cross compile for arm32 without having to edit the build system.
Based on #55778 (but not a true back-port). I can also look into doing a full back-port if there is interest, but that is kind of a braking as it will also change the name of all binaries (while this PR leaves the behavior of only changing the binary names when specifying an arch)

(while this PR leaves the behavior of only changing the binary names when specifying an arch)

Well, that was the intent, but not the current state :sweat_smile: , I'll try to fix that

So, I think this is now ready for review, and achieve the intended behavior. but...
I would suggest also adding the following patch:
diff --git a/platform/x11/detect.py b/platform/x11/detect.py
index 864a6ea442..ef28ca1c89 100644
--- a/platform/x11/detect.py
+++ b/platform/x11/detect.py
@@ -125,6 +125,9 @@ def configure(env):
     host_is_64_bit = sys.maxsize > 2**32
     is_x86_target = "x86" in env["arch"] if env["arch"] else "x86" in detect_arch()

+    if env["arch"] == "" and not is_x86_target:
+        env["arch"] = detect_arch()
+
     if env["bits"] == "default":
         env["bits"] = "64" if host_is_64_bit else "32"

@@ -135,17 +138,6 @@ def configure(env):
         env.Append(CCFLAGS=["-m64"])
         env.Append(LINKFLAGS=["-m64"])

-    machines = {
-        "riscv64": "rv64",
-        "ppc64le": "ppc64",
-        "ppc64": "ppc64",
-        "ppcle": "ppc",
-        "ppc": "ppc",
-    }
-
-    if env["arch"] == "" and platform.machine() in machines:
-        env["arch"] = machines[platform.machine()]
-

So on native platforms we retain the old .64 behavior for x86, but we always normalize the arch for other platforms.
This would affect ppc changing its name to ppc32, and any other detected arch not in the deleted list (mainly arm32 and arm64 I guess) which will not longer be named .64.

Makes sense to me. For 3.6 arm builds I pass the arch explicitly anyway so I'm already not relying on the .bits name.

I applied the suggestion by @aaronfranke and the proposed patch above.
Plus, I've applied the same changes to the server platform (which in 3.x is Linux-only, and almost a copy of the x11 detect.py).
As stated in https://github.com/godotengine/godot/pull/88369#issuecomment-1946908266 the only breaking change is the rename of the ppc platform to ppc32.


[T4A3][T10-B4]Hu JingRui

…rent class called Contact.
plus debug.

Ready for Review

Accepting this PR without a review because another of your PRs for this tutorial was reviewed in detail.


feat(selection): simple selection on row click

Good job, but I think we should release the first version (0.1.0) before merging your commit.
But don't worry, first version will probably be available next week...

Sure, let me know if I can help in any matter until then :)


Mark and filter shorts and livestream

Add some icon to indicate shorts,
also add option to filter shorts out on the feed page

there are 2 options on how to detect shorts

try a HEAD HTTP request to the URL https://www.youtube.com/shorts/[VIDEO ID] and see if it redirects you.
If you get a response HTTP status code of 200 the video is a short

make a request to the videos.list API endpoint and check that duration is less than 60 seconds

Both options result in an extra HTTP request, however option 2 can be used to also check if a video is a livestream/broadcast by checking the videos snippet.liveBroadcastContent field, or maybe the liveStreamingDetails field.
So I will most likely implement option 2, but might also provide option 1 as an alternative so no YouTube API key is needed

blocked by #24
marking uploads as shorts and live-streams requires additional table columns

for a first test I have implemented option 1
however I will HAVE to use async requests, otherwise it's going to be extremely slow

Another option would be using the shorts upload playlist ID:
https://stackoverflow.com/a/76602819

waiting for #28


standardize terminology in Components docs

partially addresses #2685

@tdykstra Looks great ... recommend tho the one-space between sentences.

@GuardRex Thank you for a thorough review as usual!  Will do on the sentence spacing.

@tdykstra Build looks good. In case you haven't seen the relative links breaking on the review site* (i.e., MSBuild and NuGet links here), you don't need to sweat them, as they'll sort themselves out on the live site with the correct domain.
*External reviewers, please use the PR diff.

@mairaw @BillWagner After the changes to the plans for this doc in the issue, we could merge this PR as an intermediate step that fixes the most egregious errors, or just close it and start over.  Which would you like to do?

Side note @tdykstra (putting on my OSS community dude hat now): This is one of the best topics MS has EVER put online. Congrats on this! :tada: 🎈 :+1: 💓 :rocket:

@GuardRex  Are you referring to this components doc or to the glossary?

@tdykstra My bad ... I meant glossary. :smile:

@BillWagner @mairaw There's more discussion in the issue (#2685) about what to do with this doc, but this PR addresses the immediate need to correct confusing terminology.  If it will be a while before we address the larger issues with the document's focus, it might be best to merge this PR in the meantime.

@terrajobst addressed feedback, is this ready to merge?

@terrajobst addressed feedback, is this ready to merge?


Error:  attribute height: A negative value is not valid

Trying out the example causes the above error. FYI, I am using angular2.

The problem is solved by adding a default height attribute to the div.


License violation

@julienschmidt if you take closer look https://github.com/kataras/iris/blob/master/http.go#L654 and lower you would clearly see that it's code from this project, with changed functions and variables names.
I've tried to contact author ( @kataras ) of violating package here: https://github.com/kataras/iris/issues/230, you can see the unfortunate result.

@kron4eg @sergeyklay  You should Read the CONTRIBUTING.MD and THIRDPARTY.MD, if you did that you would see that I added the httprouter as other libraries that Iris uses, lol *READ FIRST

@kataras Probably you should stop editing other people's comments?

@kron4eg @sergeyklay
Edited by author, reason: guidelines skipped by the commentator.
However I answer to him, because propably he is a newcomer:  Please read the THIRDPARTY  to understand what you wrote.
You should read the CONTRIBUTION file before post any new issue, you are welcome to our chat also.
@julienschmidt already knows that, I always have his link (on comments, package name and now on an MD file). I do not make license violation, I have all libraries listed, I have no reason to hide while we are faster..

@kataras Nice try. Unfortunately you pushed those edits after you the issue was opened.
Sometimes faking commit dates isn't enough.

https://www.reddit.com/r/golang/comments/4bw0yk/go_web_frameworks_a_benchmark_only_comparison/d1dte0i was also a nice attempt

@julienschmidt Go back before rc.3 (before 3-4 days)  and see where was your name please ( it was on the START OF THE MAIN ROUTER PACKAGE )

@julienschmidt  man your benchmark suite is nothing... and you know that please you should learn from this benchmark suite: https://github.com/smallnest/go-web-framework-benchmark

@julienschmidt  I have listed all libraries where is the problem with you anyway?

@AlekSi If they read the README I am answering very polite ( only 4 issues from the 204 have been edited).

@kataras I'm sorry, but don't have to stat and watch your project to point that it violates license of other people's code.

Yes or chat with me, I am not violates anything, you just hate Iris because it lives 3 months and has more stars than projects (like this) which exists more than years..anyway

If they read the README I am answering very polite ( only 4 issues from the 204 have been edited).

First, you are not polite.
Second:

https://github.com/kataras/iris/issues/200
https://github.com/kataras/iris/issues/208
https://github.com/kataras/iris/issues/211
https://github.com/kataras/iris/issues/219
https://github.com/kataras/iris/issues/225

I stopped at five because you said four. One can find much more.

@kron4eg
Yes or you could chat with me on the global iris chat, I am not violating anything, you just hate Iris because it lives 3 months and has more stars than projects (like this) which exists more than years..anyway
I answered to all questions I have nothing to hide, all libraries are listed and before your comment, and if you look back to the history you can also see julien's name in the old router, but he has some problems with me for the reason I wrote before. I have no itention to violate anything ...you should understood that.. ( although his source is slower than Iris' muxEntry's, he should learn from iris not hate it. ). End .-

@kron4eg
I am polite but my english expression is not so good, I am not native english sepaker, you missunderstood and you ever don't read my answers, so we stop now.

@kataras I have exactly two problems with you:

Your lack of respect and attempts to badmouth other people. Yes, you seem to like those GitHub stars, but don't try to get them by false claims and on the cost of others. That is not how (unsponsored) FLOSS should work (see the reddit example, unless someone managed to link your Hotmail address to their GitHub account, that was you)
httprouter/LICENSE is the other one

See also https://github.com/kataras/iris/issues/15

@julienschmidt Did you know that I left from university for iris?

See also kataras/iris#15

That I told at the first place and you start to speak me like I am your wife..

@kataras Read the license and respect it. And stop using HttpRouter or any other of my software for questionable comparisons.
The other option is a cease-and-desist letter. We are both in the EU after all.


Magento 2.4.4 & updated system reqs / docker image versions

As of Tues, March 29, 2022, the new version of Adobe Commerce 2.4.4 / Magento 2.4.4 is open for testing purposes. (general availability coming on April 12) Reqs here: https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements.html
I haven't done any testing yet, but the new Magento 2.4.4 would seem to require newer Docker container image versions (newer than what is available at https://hub.docker.com/u/wardenenv). Magento 2.4.4 would seem to require:

Elasticsearch 7.17 or OpenSearch 1.2 (only Elasticsearch up to 7.13 is available)
Rabbitmq 3.9 (only up to 3.8 available)
Reddis 6.2 (only up to 6.0 available)
Varnish 7.0 (only up to 6.5 available)

Can new Docker containers be made available?
Thanks, Kraig

@kraiglarson Images for each of these should be available now, as they were added in #505 and #495


Dvorak layout

I see in codeboard/app/src/main/res/xml there is a dvorak.xml which, being very new to coding, I assume means I could add that layout to my codeboard app... if this is correct, how would I do it, and if not, how can I help you add it as an option?

+1

I also would like this. It's a must have for me.


[Bug]: Unable to migrate snowflake_role_grants to snowflake_grant_account_role

Terraform CLI Version
v1.9.1
Terraform Provider Version
v0.96.0
Terraform Configuration
Old resource from version 0.92 of this provider
resource "snowflake_role_grants" "ci" {
  role_name = snowflake_role.ci.name
  roles = [...]
  users = [
    snowflake_user.ci.name,
  ]
}

New resource from version 0.96 of this provider
resource "snowflake_grant_account_role" "grant_role_ci_to_ci_user" {
  role_name = snowflake_role.ci.name
  user_name = snowflake_user.ci.name
}

Category
category:resource
Object type(s)
resource:grant_account_role
Expected Behavior
I should be able to terraform state rm the old resource and terraform import the new resource as generally described here.
Actual Behavior
TF_LOG=DEBUG terraform import module.snowflake_ci.snowflake_grant_account_role.grant_role_ci_to_ci_user "CI_ROLE|USER|CI_USER"

# Debug output snipped for brevity, but I can see this somewhere in the middle of it...

2024-10-10T14:40:28.464-0400 [DEBUG] provider.terraform-provider-snowflake_v0.96.0: 2024/10/10 14:40:28 [DEBUG] sql-conn-query: [query SHOW GRANTS OF ROLE "CI_ROLE" err <nil> duration 210.559375ms args {}] (LOC12345)
2024-10-10T14:40:28.465-0400 [DEBUG] provider.terraform-provider-snowflake_v0.96.0: 2024/10/10 14:40:28 Failed to parse identifier [], err = "incompatible identifier: "; falling back to fully qualified name conversion
2024-10-10T14:40:28.465-0400 [DEBUG] provider.terraform-provider-snowflake_v0.96.0: 2024/10/10 14:40:28 Failed to parse identifier [], err = "incompatible identifier: "; falling back to fully qualified name conversion
2024-10-10T14:40:28.465-0400 [DEBUG] provider.terraform-provider-snowflake_v0.96.0: 2024/10/10 14:40:28 [DEBUG] role grant (CI_ROLE|USER|CI_USER) not found
2024-10-10T14:40:28.465-0400 [WARN]  Provider "registry.terraform.io/snowflake-labs/snowflake" produced an unexpected new value for module.snowflake_ci.snowflake_grant_account_role.grant_role_ci_to_ci_user during refresh.
       Only pre-existing objects can be imported; check that the id is correct and that it is
│ associated with the provider's configured region or endpoint, or use "terraform apply" to create a new remote object for this resource.

Steps to Reproduce
Attempt to migrate from an old snowflake_role_grants resource to a new snowflake_grant_account_role resource by way of terraform state rm ... && terraform import ....
How much impact is this issue causing?
Medium
Logs
No response
Additional Information
$ terraform state show module.snowflake_ci.snowflake_user.ci
# module.snowflake_ci.snowflake_user.ci:
resource "snowflake_user" "ci" {
    comment                        = null
    default_namespace              = null
    default_role                   = "CI_ROLE"
    default_secondary_roles_option = "NONE"
    default_warehouse              = "CI_COMPUTE_WH"
    disabled                       = "false"
    display_name                   = (sensitive value)
    email                          = (sensitive value)
    first_name                     = (sensitive value)
    id                             = "CI_USER"
    last_name                      = (sensitive value)
    login_name                     = (sensitive value)
    must_change_password           = "false"
    name                           = (sensitive value)
    password                       = (sensitive value)
}

$ terraform state show module.snowflake_ci.snowflake_role.ci
# module.snowflake_ci.snowflake_role.ci:
resource "snowflake_role" "ci" {
    comment = "CI_ROLE"
    id      = "CI_ROLE"
    name    = "CI_ROLE"
}

Would you like to implement a fix?

[ ] Yeah, I'll take it 😎

Hey @jrobison-sb. Thanks for reaching out to us.
Thank you for the detailed description! I will validate the behavior in the morning, but an idea I have now (and it seems to change the execution slightly) is to have CI_ROLE and CI_USER both wrapped in double quotes in the import statement. The docs for import also suggest this: https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/grant_account_role#import.
The reason lies in these two lines: https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/d837341c2d18b6fbb4657ad3a1837190a8ee77d8/pkg/resources/grant_account_role.go#L124 and https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/d837341c2d18b6fbb4657ad3a1837190a8ee77d8/pkg/resources/grant_account_role.go#L140
Can you please check if this makes the import succeed?

@sfc-gh-asawicki
Slashy escape quotes unblocked me on this. Thanks for your help.


Docker Link of glacier simulator is not working

Hi @TimoRoth,
the docker link of the glacier simulator is not working and maybe you can help.
You changed the docker links here https://github.com/OGGM/oggm-edu/commit/b36de29b4ea0c609c22fba367e771832c511f1af and explained on slack that the ports I was using for the simulator were not best practice (as <IP_ADDRESS> just means 'any IP'). I just checked again and with docker run -e BOKEH_ALLOW_WS_ORIGIN=<IP_ADDRESS> -p 8085:8080 oggm/bokeh:20210130 git+https://github.com/OGGM/glacier_simulator.git@stable app.ipynb and accessing with http://<IP_ADDRESS>:8085/app the app is not starting.
However the bad practice example with docker run -e BOKEH_ALLOW_WS_ORIGIN=<IP_ADDRESS>:8080 -p 8080:8080 oggm/bokeh:20210130 git+https://github.com/OGGM/glacier_simulator.git@stable app.ipynb and accessing with http://<IP_ADDRESS>:8080/app is working.
Is it only a problem on my side? (I just reinstalled and updated docker)
Do you have an idea what can cause the problem?

Accessing via "http://<IP_ADDRESS>:8080/app" straight up cannot work, since <IP_ADDRESS> is not a valid IP address to connect to.
Listening on it only means to allow connections from anywhere.
It for that reason also does not work in the ALLOW_WS_ORIGIN field, since the origin will never be <IP_ADDRESS>, but always <IP_ADDRESS>, localhost, your machines actual address, or something like that.
I just tested the exact command for the glacier_simulator from the docs:
docker run -e BOKEH_ALLOW_WS_ORIGIN=<IP_ADDRESS> -p 8085:8080 oggm/bokeh:20210130 git+https://github.com/OGGM/glacier_simulator.git@stable app.ipynb and it works absolutely fine for me.
The link it prints is obviously wrong and can't ever work, given it contains <IP_ADDRESS>, which internally in the container is the correct address to listen on.
After I ran that command, I could reach the application on http://<IP_ADDRESS>:8085.
Same for the other two in the docs. They all work as expected for me.

I can't really think of a reason why it would not work. It's pretty universal.
And something must be very wrong, or your Browser implicitly replaces it with localhost, if you can connect to <IP_ADDRESS>.
Connecting to that address makes no logical sense, since it's not an address anything can have. It's just the "any address" value when opening a listening socket. Which means to listen on every available address of that host.
The address/hostname in BOKEH_ALLOW_WS_ORIGIN has to match the one in the Browsers address field. It's just a security measure browsers mandate.
The app will always listen on <IP_ADDRESS>, port 8080, in the container. And docker then translates that to a different Port on the host. Like for example 8085.
I just noticed that for the glacier_simulator app specifically the link in the docs only got a partial update.
The link target didn't get the correct port. Maybe that's what was tripping you up?

Yes, the wrong link was the problem, as I just clicked on it on the website. Now it is working fine.
Thank you!

Can you send a fix to the website?

It is already fixed on the website, at least for me


chore(deps): update dependency web-ext to v7

This PR contains the following updates:

Package
Type
Update
Change

web-ext
devDependencies
major
6.8.0 -> 7.0.0

web-ext
dependencies
major
^6.1.0 -> ^7.0.0

Release Notes

mozilla/web-ext
v7.0.0
Compare Source
:warning: BREAKING CHANGES :warning:

web-ext npm package is now a pure ESM package (#2405), and so it breaks backward compatibility for requiring web-ext from nodejs CommonJS modules. See Using web-ext in NodeJS code README section for some more updated details about the web-ext APIs exported as web-ext ES Modules.

Dropped support for NodeJS 12 :wave:

Features

web-ext lint: Updated to use addons-linter v5.7.0 (#2400, #2404, #2425)

Imported Firefox 99.0b8, Firefox 100 and Firefox 101.0b6 API Schema data
Updated @mdn/browser-compat-data to v5
Added detection and reporting of privileged permissions and properties based on the extension manifest.json file
Allow wasm-unsafe-eval keyword in the custom extension CSP
See all addons-linter changes: 4.14.0...5.7.0

web-ext lint: Added a new --privileged CLI flag to enable privileged extensions linting mode (#2398)

Bug Fixes

Dependencies updates:

camelcase to v7 (#2414, #2419)
chrome-launcher to v0.15.1 (#2410)
debounce to v1.2.1 (#2190)
decamelize to v6 (#2325, #2420)
fs-extra to v10 (#2237)
multimatch to v6 (#2421)
node-notifier to v10 (#2194, #2255)
open to v8 (#2175)
parse-json to v6 (#2422)
promise-toolbox to v0.21.0 (#2415)
sign-addon to v5 (#2423, #2426)
source-map-support to v0.5.21 (#2411)
strip-bom to v5 (#2224)
strip-json-comments to v4 (#2301)
watchpack to v2.4.0 (#2253)
ws to v8 (#2270, #2288)
yargs to v17 (#2235)
@devicefarmer/adbkit to v3.2.3 (#2397)

See all changes 6.8.0...7.0.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
As this PR has been closed unmerged, Renovate will ignore this upgrade and you will not receive PRs for any future 7.x releases. However, if you upgrade to 7.x manually then Renovate will reenable minor and patch updates automatically.
If this PR was closed by mistake or you changed your mind, you can simply rename this PR and you will soon get a fresh replacement PR opened.


Add string type to argument of fetchEnsAvatar to allow for name entry

Description
Add string type to fetchEnsAvatar to match the comment "or ENS name"
Additional Information

[x] I read the contributing docs

Your ENS/address: luc.computer

Hey! If you want to fetch the ENS avatar by ENS name, you should compose the fetchEnsAddress action:
import { fetchEnsAddress, fetchEnsAvatar } from '@wagmi/core'

const address = await fetchEnsAddress({ name: 'awkweb.eth' })
const avatar = await fetchEnsAvatar({ address })

It does say "address or ens name" in the doc comment, and it works with ens-names. So the type is not correct.

In the comments on line 6 it says "or ENS name"

@tmm Could you have another look at this?

We should remove  or ENS name then. LMK if you want to do it (for the credit). Otherwise, I can.


luci-base: TypeError on every page

Steps to reproduce:

Go to any page in LuCI

Actual behavior:

Page loads with red error label with text: "TypeError_(...).format is not a function".  It fixes after several refreshes.

Expected behavior:

Page loads without any errors.

Additional Information:
LuCI openwrt-23.05 branch (git-24.073.29889-cd7e519) / OpenWrt 23.05.3 (r23809-234f1a2efa)
OpenWrt version information from system /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='23.05.3'
DISTRIB_REVISION='r23809-234f1a2efa'
DISTRIB_TARGET='bcm27xx/bcm2711'
DISTRIB_ARCH='aarch64_cortex-a72'
DISTRIB_DESCRIPTION='OpenWrt 23.05.3 r23809-234f1a2efa'
DISTRIB_TAINTS=''

crypto.randomUUID(),page.js and injectedScript.bundle.js do not belong to LuCI. I suspect a browser extension or some intermediate proxy is mangling the markup/scripts.

crypto.randomUUID(),page.js and injectedScript.bundle.js do not belong to LuCI. I suspect a browser extension or some intermediate proxy is mangling the markup/scripts.
Some cursory internet research hints at a "MetaMask Chrome Extension" which commonly interferes with stuff...

Yeah, you are absolutely right, LuCI without extensions works perfectly. However, diasbling MetaMask extension didn't fix the problem. May be there is another extension that inteferes as well. Thank you!


Include X-Size-Limit in doc/openapi

For utilities/view and utilities/download

Hi @chrisjsewell , this was included in current release.
Let us know if this solves this issue.
Cheers

Closing this issue.


 If you
click Continue, the application will ignore this error and attempt
to continue. If you click Quit, the application will close
immediately.
The system cannot find the file specified. (0x80070002).

To Reproduce
Steps to reproduce the behavior:

Download and install offline release on an older version of Windows 11/10
Open Simple-Browser

Expected behavior
Simple Browser Will Open to setup
Screenshots

Pulled from Here
Desktop (please complete the following information):

OS: Windows (Any Version)
Browser: Any
Version:

Smartphone (if applicable):
N/A
Additional context
Solution Below:

The fix is the following:
!! (FOR WINDOWS 10 1809 and LATER)
Download the Browser runtime: https://go.microsoft.com/fwlink/p/?LinkId=2124703
Install it and try again.

If you still experience this, please make a new issue.

Forgot to close this 😂