Merge master into live-based

Docs Build status updates of commit 36c8bc7:
:warning: Validation status: warnings

File
Status
Preview URL
Details

developer/cmdlet/creating-a-cmdlet-to-access-a-data-store.md
:warning:Warning
View
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

reference/3.0/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/3.0/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/3.0/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/3.0/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/4.0/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/4.0/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/4.0/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/4.0/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/5.0/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.0/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.0/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.0/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.1/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Utility/Invoke-WebRequest.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/6/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Utility/ConvertFrom-Markdown.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Utility/Invoke-WebRequest.md
:white_check_mark:Succeeded
View (powershell-6)

reference/7/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Utility/ConvertFrom-Markdown.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Utility/Invoke-WebRequest.md
:white_check_mark:Succeeded
View (powershell-7)

developer/cmdlet/creating-a-cmdlet-to-access-a-data-store.md

Line 376: [Warning] Illegal link: `<a href="#Defining-the-Cmdlet-Class">Building the Cmdlet</a>` -- missing bookmark. The file cmdlet/creating-a-cmdlet-to-access-a-data-store.md doesn't contain a bookmark named Defining-the-Cmdlet-Class. NOTE: This Suggestion will be elevated to a Warning on 8/26/2019. Please fix invalid bookmarks as soon as possible.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit db0b6fc:
:clock10: Pending: waiting for processors (29 builds ahead of you)
:warning: Docs Build is busy, currently there are 29 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit db0b6fc:
:warning: Validation status: warnings

File
Status
Preview URL
Details

.openpublishing.redirection.json
:warning:Warning

Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

developer/cmdlet/creating-a-cmdlet-to-access-a-data-store.md
:white_check_mark:Succeeded
View

reference/3.0/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/3.0/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/3.0/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/3.0/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/3.0/Microsoft.PowerShell.Utility/Select-String.md
:white_check_mark:Succeeded
View (powershell-3.0)

reference/4.0/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/4.0/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/4.0/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/4.0/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/4.0/Microsoft.PowerShell.Utility/Select-String.md
:white_check_mark:Succeeded
View (powershell-4.0)

reference/5.0/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.0/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.0/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.0/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.0/Microsoft.PowerShell.Utility/Select-String.md
:white_check_mark:Succeeded
View (powershell-5.0)

reference/5.1/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Utility/Invoke-WebRequest.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/5.1/Microsoft.PowerShell.Utility/Select-String.md
:white_check_mark:Succeeded
View (powershell-5.1)

reference/6/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Utility/ConvertFrom-Markdown.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Utility/Invoke-WebRequest.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Utility/Select-String.md
:white_check_mark:Succeeded
View (powershell-6)

reference/6/Microsoft.PowerShell.Utility/Show-Markdown.md
:white_check_mark:Succeeded
View (powershell-6)

reference/7/Microsoft.PowerShell.Core/Get-Help.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Core/Set-PSDebug.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Core/Set-StrictMode.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Management/Get-Content.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Utility/ConvertFrom-Markdown.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Utility/Invoke-WebRequest.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Utility/Select-String.md
:white_check_mark:Succeeded
View (powershell-7)

reference/7/Microsoft.PowerShell.Utility/Show-Markdown.md
:white_check_mark:Succeeded
View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/audit-and-report.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/overview.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/prerequisites.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/register-jea.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/role-capabilities.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/security-considerations.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/session-configurations.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/learn/remoting/jea/using-jea.md
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

reference/docs-conceptual/toc.yml
:white_check_mark:Succeeded
View (powershell-3.0) View (powershell-4.0) View (powershell-5.0) View (powershell-5.1) View (powershell-6) View (powershell-7)

.openpublishing.redirection.json

[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/audit-and-report.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.
[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/overview.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.
[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/prerequisites.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.
[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/register-jea.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.
[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/role-capabilities.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.
[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/security-considerations.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.
[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/session-configurations.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.
[Warning] Master redirection file .openpublishing.redirection.json has a redirection rule on file 'jea/using-jea.md'. However, the file already exists in the Git repo in conflict with the redirection rule. Docs will ignore the file and populate with the redirection rule instead. To resolve this warning, please remove the original file in Git repo.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Dependabot failures

Describe the task
Currently dependabot is failing due to the following issue

Acceptance Criteria

[ ] fix dependabot issue

Merged the PRs for the security alerts.


Intentional special casing of periods in form keys limits real-world usage

Due to the intentional special casing of periods within form, any API which uses periods in a form field cannot be interacted with without some hacks. For example, the fastly API utilizes periods in their form fields: https://docs.fastly.com/api/config#settings_9740ff4ac0c1777f455274c4850ece23
The go-fastly library attempted to work around this by manually ripping out the generated escapes, but that leads to other things being unintentionally ripped out, as noted in this case: https://github.com/sethvargo/go-fastly/issues/11
Is there any workaround for interacting with forms which have periods in their form keys?

Test case demonstrating the problem:
package main

import (
        "fmt"
        "github.com/ajg/form"
)

func main() {
        type test struct {
                Foo string `form:"general.default_ttl,omitempty"`
        }
        testing := test{Foo: "bar"}
        values, _ := form.EncodeToValues(testing)
        fmt.Println(values.Encode())
}

Output:
general%5C.default_ttl=bar

The addition of the backslash will not be accepted by the form recipient.

@alienth I opened a PR with support for custom delimiter & escape support (https://github.com/ajg/form/pull/10/files). So in your example, you'd be able to do e.g.:
form.NewEncoder(os.Stdout).DelimitWith('/').Encode(testing)

Would that solve your problem?

@ajg Verified that using something like this will address my problem.

@alienth glad to hear it; will merge shortly.


Design exception types/hierarchy

This PR introduces Realm exception handling. Our concept is that the SDK should treat Realm-core as a separate library with a defined boundary. We achieve this by defining an intermediate representation of core errors to be consumed by the SDK, instead of mapping directly Core errors to end-user exceptions.
The common C-interop package maps raw Core errors types into Kotlin throwables and each c-interop specialization (swig, native) map the exceptions to their internal representation of the core error types. Those exceptions are exposed to the SDK that would decide if it has to wrap the exception in some more user-friendly one or to perform some specific logic.
Here is an example of how a Core error maps into a end-user exception:
SDK                    -> IllegalArgumentException(cause: RealmCoreDuplicatePrimaryKeyException)
C-interop (Common)     -> RealmCoreDuplicatePrimaryKeyException
C-interop (Darwin)     -> ErrorType.RLM_ERR_DUPLICATE_PRIMARY_KEY_VALUE
Core (Darwin wrapper)  -> realm_wrapper.RLM_ERR_DUPLICATE_PRIMARY_KEY_VALUE

This design gives flexibility and enough granularity to the SDK on how to react to Core exceptions. For example, the same Core exception can be rethrown to the user as an IllegalStateException on regular Realms, or as an IllegalArgumentException on Dynamic Realms.
Status

[x] C-Interop to expose core exceptions.
[x] Support multi-platform.
[ ] Map all core error types to specific Exceptions.
[ ] Refactor RuntimeExceptions to actual exception types.

I think the general principle in this PR is great. I have slight concerns about us ending up with a ton of internal exception classes, but maybe it is the best compromise? 🤔

Yeah, to me it also looks like the wrong way to go with all these specific core exceptions. If it is a matter of being able to selectively only catch some core exceptions and rethrow based on specific core exception type I would imagine that we could do a utility method that is rethrowing based on specific error codes
mapError(
  RLM_ERR_INVALID_ARGUMENT to { it -> IllegalArgumentException("....", it) },
  RLM_ERR_LOGIC to { it -> IllegalStateException("....", it) },
)

Or something like that. Wouldn't that enable us to achieve the same, but without having to maintain an unrealistic amount of exceptions.


Added Countdown timer

Added CountDown Timer component.
The set value can be changed in the default Prop in the Timer component.

Thanks @eeshdarthvader for your great works


vertical tabbed window panes - query pane unreadable when results and or messages displayed

Issue Type: Bug
new query window, short sql
copy sql, new query window, move below current pane so vertical
run sql in new query pane, results and or messages appear and the query pane appears blank.
resize query pane upwards and sql begins to appear once larger than half ADS window size.
cannot hide or remove results/messages to get query back
seperate request - can we can Results and messages as per SSMS to remove these types of issues
Azure Data Studio version: azuredatastudio 1.6.0 (eb35dae1d1238e03f1cab3bd45e151f381b22aef, 2019-04-17T07:11:15.944Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz (8 x 2808)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.89GB (8.02GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

@nige6 we are actively looking at how to improve the query editor to address this type of issue.

This should be fixed\improved in the June release.  Please let me know if there is additional feedback in this area.


Nested Query Support

[x] Support COMPARE_IN operation in Type J and N queries

[x] Add transformation rule from LogicalSingleJoin to LogicalInnerJoin

[x] Materialization for AggregateAndGroupBy nodes

[x] Add junit test

Closed to reduce Jenkins contention


How can we reproduce this bad token exception

I found this exception randomly while testing my app and I am using toasts on a lot of places, it turns out I am running the app on a device with api 25, and  you library seems to be the way forward.
Is it possible to provide a code from which I could reproduce this issue?

Toast.makeText(this，"test"，Toast.LENGTH_SHORT).show();
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}


Open dialog on clicking Whois info

Issue
When clicking the Whois info in the chat log, the About character dialog should open up.
See discussion on Wolfery forum:
https://forum.wolfery.com/t/thumbnail-zooming/1597
Notes

Hovering the Whois "badge" area should make it a slightly darker color
Hovering should change the cursor to indicate it is clickable
The whois command is handle by the whois module (Whois.js).
The About character dialog is handled by the dialogAboutChar module (DialogAboutChar.js).

Resolved in commit bf6d96bc03a59cd21036b63f51cc2c5d1367b476


PLEG errors with v20221027

What happened:
We noticed an increased rate of PLEG errors while running our workload with v20221027 AMI release. The same issue doesn't appear with v20220926.
What you expected to happen:
PLEG errors shouldn't appear with latest AMI
How to reproduce it (as minimally and precisely as possible):
This issue can be easily reproduced with high CPU/memory workloads
Anything else we need to know?:
So far it looks like an issue associated with the latest kernel version 5.4.217-126.408.amzn2.
Environment:

AWS Region:
Instance Type(s):
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion):
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version):
AMI Version:
Kernel (e.g. uname -a):
Release information (run cat /etc/eks/release on a node):

@ravisinha0506 since you're tracking this, we're seeing the same issues on AMIs built after kernel-5.4.214-120.368.amzn2
https://alas.aws.amazon.com/AL2/ALASKERNEL-5.4-2022-036.html

Prior to this latest release we attempted to upgrade the kernel on top of the AMI Release v20220926.  We experienced instability when doing this.  So we decided to wait for this latest release with the kernel upgrades that patch the latest CVEs.  Unfortunately we experienced the same issues. We are reasonably confident this due to the kernel upgrade.
The issues that we are seeing now are mostly related to readiness probes using exec commands.  They are failing at a much higher rate. It seems to be either a latency issue or some sort of race condition causing the failures.  It also noteworthy we see these failures on high volume pods/nodes.
Kernel version
5.4.217-126.408.amzn2.x86_64
OS Image
Amazon Linux 2
Container runtime version
containerd://1.6.6
kubelet version
v1.22.12-eks-ba74326
kube-proxy version
v1.22.12-eks-ba74326
Operating system
linux
Architecture
amd64

@mschenk42 Seconding this - we experienced the same instability with v20220926 and the new kernel. We had to roll-back.

We are also experiencing the same issue with with v20221027.

I am not sure if it is directly related with this, but since more or less 2 weeks ago (possibly more) we are having a lot of node health flappiness.
Some investigation revealed a network socket leak somewhere in the docker service. In some nodes socket count grows steady until the health of the node starts to flap. After that the nodes start to behave bad, not terminating pods, having random connectivity issues, etc...
The socket count of pods is normal, but the socket count of the node is too high an drops down to normal levels if the docker service is restarted.
Environment:
Amazon Linux 2
BASE_AMI_ID="ami-02dd04850de58599e"
BUILD_TIME="Mon Sep 26 21:55:27 UTC 2022"
BUILD_KERNEL="5.4.209-116.367.amzn2.x86_64"
ARCH="x86_64"
Container runtime version
Docker 20.10.17
Kubernetes version:
v1.21.14
We have reverted to an old AMI until we figure out what is going on

We have been looking into this issue as well in our clusters and have been seeing singular containers on some nodes enter a state where no docker commands complete when interacting with the container. As mentioned, this was first seen in the kernel-5.4.214-120.368.amzn2 version. I'll post some of our investigation here in case it is useful.
Node events show flapping between NodeReady and NodeNotReady
Events:
  Type    Reason        Age                     From     Message
  ----    ------        ----                    ----     -------
  Normal  NodeReady     3m11s (x15 over 4d20h)  kubelet  Node ip-10-32-145-43.ec2.internal status is now: NodeReady
  Normal  NodeNotReady  10s (x15 over 56m)      kubelet  Node ip-10-32-145-43.ec2.internal status is now: NodeNotReady

That NodeNotReady status seems to come from the K8s PLEG failing
KubeletNotReady              PLEG is not healthy: pleg was last seen active 3m7.341793557s ago; threshold is 3m0s

All docker commands with affected pod hang, but others complete just fine
.:/home/kevin_simons$ docker inspect de3577202e88
^C
.:/home/kevin_simons$ docker kill de3577202e88
^C

.:/home/kevin_simons$ docker inspect 4c53f702cd55
[
    {
        "Id": "4c53f702cd556d79c4787c96dc8f133c80a5791909822b50e2f6470517985b85",
        "Created": "2022-11-01T15:36:41.844751335Z",
        "Path": "/init/init.sh",
...

The affected container seems to have an additional runc process compared to other working containers.
.:/home/kevin_simons$ ps -aux | grep de3577202e88
root      8856  0.0  0.0 1174840 10412 ?       Sl   11:24   0:00 runc --root /var/run/docker/runtime-runc/moby --log /run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/log.json --log-format json exec --process /tmp/runc-process1560347957 --detach --pid-file /run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8
root     19055  0.0  0.0<PHONE_NUMBER>0 ?        Sl   Nov01   1:04 /usr/bin/containerd-shim-runc-v2 -namespace moby -id de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8 -address /run/containerd/containerd.sock
root     19747  0.0  0.0 119424   916 pts/0    S+   19:11   0:00 grep --color=auto de3577202e88

.:/home/kevin_simons$ ps -aux | grep 6adcc2ab7a4d
root     19850  0.0  0.0 119424   960 pts/0    S+   19:11   0:00 grep --color=auto 6adcc2ab7a4d
root     27816  0.0  0.0<PHONE_NUMBER>4 ?        Sl   Nov01   0:05 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 6adcc2ab7a4dd25bfc93f96c440c5be97cd4afe82ffbddedd9217641a7d96a66 -address /run/containerd/containerd.sock

The strace of that runc process
:/home/kevin_simons$ strace -s 800 -T -y -yy -f -p 8856
strace: Process 8856 attached with 7 threads
[pid  8868] futex(0xc000280148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  8864] futex(0x55ea78bd4558, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  8863] futex(0xc000080148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  8862] futex(0x55ea78ba5db8, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000009>
[pid  8861] futex(0x55ea78bd46a0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  8862] read(9<pipe:[43673545]>, "", 4096) = 0 <0.000009>
[pid  8860] restart_syscall(<... resuming interrupted read ...> <unfinished ...>
[pid  8862] epoll_ctl(4<anon_inode:[eventpoll]>, EPOLL_CTL_DEL, 9<pipe:[43673545]>, 0xc00003c654 <unfinished ...>
[pid  8860] <... restart_syscall resumed> ) = -1 EAGAIN (Resource temporarily unavailable) <0.000029>
[pid  8862] <... epoll_ctl resumed> )   = 0 <0.000073>
[pid  8860] nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>
[pid  8862] close(9<pipe:[43673545]>)   = 0 <0.000017>
[pid  8856] futex(0x55ea78ba47a8, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  8862] futex(0xc000280148, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid  8868] <... futex resumed> )       = 0 <0.000335>
[pid  8862] <... futex resumed> )       = 1 <0.000028>
[pid  8868] epoll_pwait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid  8860] <... nanosleep resumed> NULL) = 0 <0.000120>
[pid  8868] <... epoll_pwait resumed> [], 128, 0, NULL, 0) = 0 <0.000020>
[pid  8862] openat(AT_FDCWD, "/run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/.4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid", O_RDWR|O_CREAT|O_EXCL|O_SYNC|O_CLOEXEC, 0666 <unfinished ...>
[pid  8868] epoll_pwait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid  8862] <... openat resumed> )      = 7</run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/.4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid> <0.000020>
[pid  8860] nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>
[pid  8862] epoll_ctl(4<anon_inode:[eventpoll]>, EPOLL_CTL_ADD, 7</run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/.4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid>, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=678758216, u64=139793274308424}}) = -1 EPERM (Operation not permitted) <0.000011>
[pid  8862] write(7</run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/.4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid>, "8874", 4) = 4 <0.000015>
[pid  8860] <... nanosleep resumed> NULL) = 0 <0.000094>
[pid  8862] close(7</run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/.4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid> <unfinished ...>
[pid  8860] nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>
[pid  8862] <... close resumed> )       = 0 <0.000018>
[pid  8862] newfstatat(AT_FDCWD, "/run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid", 0xc0000a6928, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) <0.000012>
[pid  8862] renameat(AT_FDCWD, "/run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/.4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid", AT_FDCWD, "/run/containerd/io.containerd.runtime.v2.task/moby/de3577202e889e348167c45b691e8b8401670f0307d6e947f44d2325752f7ed8/4c05038461d26b103f30fbff51626f9ab0a44e128d4575a23172318776df772e.pid" <unfinished ...>
[pid  8860] <... nanosleep resumed> NULL) = 0 <0.000082>
[pid  8862] <... renameat resumed> )    = 0 <0.000020>
[pid  8860] nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>
[pid  8862] exit_group(0 <unfinished ...>
[pid  8868] <... epoll_pwait resumed> [{0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|EPOLLEXCLUSIVE|0xb5fd800, {u32=32548, u64=8653847918727429924}}, {EPOLLPRI|EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|0x5000, {u32=180224, u64=824633901056}}, {EPOLLERR|EPOLLRDNORM|EPOLLWRNORM|0x80000, {u32=192, u64=554050781376}}, {EPOLLIN, {u32=147488, u64=824633868320}}, {0, {u32=0, u64=0}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=1, u64=94463510708225}}, {EPOLLRDBAND, {u32=16777216, u64=4311744512}}, {0, {u32=1, u64=1}}, {0, {u32=0, u64=0}}, {0, {u32=524616, u64=824634245448}}, {0, {u32=0, u64=4294967296}}, {0, {u32=1, u64=1}}, {EPOLLOUT, {u32=0, u64=17179869184}}, {0, {u32=2014802745, u64=94465525510969}}, {EPOLLNVAL|0x24000, {u32=192, u64=633438956683456}}, {EPOLLRDNORM|EPOLLRDBAND, {u32=2014796893, u64=94465525505117}}, {EPOLLERR|EPOLLHUP|EPOLLNVAL|EPOLLRDNORM|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|EPOLLEXCLUSIVE|EPOLLONESHOT|0x1905000, {u32=32548, u64=774056185986852}}, {EPOLLRDNORM|EPOLLRDBAND, {u32=0, u64=0}}, {EPOLLNVAL|EPOLLRDBAND|EPOLLWRNORM|EPOLLRDHUP|0x280000, {u32=192, u64=5877328870998278336}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=188416, u64=824633909248}}, {EPOLLERR|EPOLLNVAL|EPOLLWRBAND|EPOLLMSG|EPOLLEXCLUSIVE|0xb5fd800, {u32=32548, u64=8653867727116599076}}, {EPOLLPRI|EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|0x5000, {u32=16384, u64=16384}}, {EPOLLERR|EPOLLHUP|EPOLLNVAL|EPOLLRDNORM|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|EPOLLEXCLUSIVE|EPOLLONESHOT|0x1905000, {u32=32548, u64=2915158371545939748}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=0, u64=0}}, {EPOLLNVAL|EPOLLRDBAND|EPOLLWRNORM|EPOLLRDHUP|0x280000, {u32=192, u64=8652919497121857728}}, {EPOLLPRI|EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|0x5000, {u32=459267656, u64=139793054817864}}, {EPOLLERR|EPOLLHUP|EPOLLRDNORM|EPOLLWRBAND|EPOLLMSG|EPOLLEXCLUSIVE|0xb5fd800, {u32=32548, u64=8653873585451990820}}, {EPOLLPRI|EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|0x5000, {u32=8608, u64=824633729440}}, {EPOLLPRI, {u32=4, u64=11295970146910212}}, {EPOLLRDNORM|EPOLLRDBAND, {u32=8608, u64=824633729440}}, {EPOLLNVAL|EPOLLWRBAND|EPOLLMSG|0x198000, {u32=192, u64=8654521438318887104}}, {EPOLLPRI|EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|0x5000, {u32=8608, u64=824633729440}}, {0, {u32=0, u64=45035996273704960}}, {0, {u32=0, u64=0}}, {EPOLLNVAL|EPOLLRDBAND|EPOLLWRNORM|EPOLLRDHUP|0x280000, {u32=192, u64=11295970146910400}}, {EPOLLRDNORM|EPOLLRDBAND, {u32=2015037669, u64=94465525745893}}, {EPOLLIN|EPOLLPRI|EPOLLOUT|EPOLLERR|EPOLLWRNORM|EPOLLRDHUP|EPOLLEXCLUSIVE|EPOLLWAKEUP|EPOLLONESHOT|0x853c800, {u32=21994, u64=2017589886915204586}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=2043835376, u64=94465554543600}}, {EPOLLIN|EPOLLPRI|EPOLLOUT|EPOLLERR|EPOLLHUP|EPOLLRDNORM|EPOLLWRBAND|EPOLLRDHUP|EPOLLEXCLUSIVE|0xbffc800, {u32=32548, u64=2017588847533129508}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=2630048, u64=824636350880}}, {EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLEXCLUSIVE|EPOLLWAKEUP|EPOLLONESHOT|0x81b0800, {u32=21994, u64=8670523657535116778}}, {EPOLLPRI|EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|0x5000, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=1365869643, u64=139793961419851}}, {0, {u32=0, u64=1972549148997582848}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=459269888, u64=139793054820096}}, {EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|EPOLLEXCLUSIVE|EPOLLONESHOT|0x6124800, {u32=765780331, u64=2017588848298877291}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=469756511, u64=139793065306719}}, {EPOLLHUP|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLWRBAND|EPOLLRDHUP|EPOLLEXCLUSIVE|EPOLLWAKEUP|EPOLLONESHOT|0x9d25000, {u32=21994, u64=2017589886915204586}}, {EPOLLOUT|EPOLLNVAL|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|0x5800, {u32=3893522394, u64=15270817745933070298}}, {EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|EPOLLEXCLUSIVE|EPOLLONESHOT|0xe364800, {u32=3555476408, u64=3555476408}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=9331877341841850368}}, {EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLRDHUP|EPOLLET|0x7f49800, {u32=0, u64=0}}, {EPOLLWRNORM|EPOLLWRBAND|EPOLLMSG|EPOLLRDHUP|EPOLLEXCLUSIVE|0xb5fc000, {u32=32548, u64=8778206098327895844}}, {EPOLLPRI|EPOLLERR|EPOLLNVAL|EPOLLRDNORM|EPOLLRDBAND|EPOLLWRNORM|EPOLLMSG|0x5000, {u32=1360582031, u64=139793956132239}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}, {0, {u32=0, u64=0}}], 128, -1, NULL, 0) = 231 <0.000324>
[pid  8864] <... futex resumed>)        = ?
[pid  8868] +++ exited with 0 +++
[pid  8863] <... futex resumed>)        = ?
[pid  8864] +++ exited with 0 +++
[pid  8862] <... exit_group resumed>)   = ?
[pid  8863] +++ exited with 0 +++
[pid  8861] <... futex resumed>)        = ?
[pid  8862] +++ exited with 0 +++
[pid  8861] +++ exited with 0 +++
[pid  8860] <... nanosleep resumed> <unfinished ...>) = ?
[pid  8856] <... futex resumed>)        = ?
[pid  8860] +++ exited with 0 +++
+++ exited with 0 +++

We then see that after running strace on that runc process, the container is automatically cleaned up and the node seems to go back to a Ready state.
.:/home/kevin_simons$ docker inspect de3577202e88
[]
Error: No such object: de3577202e88

At this point I hopped on another broken node since that one was cleaned up.
Running strace on the containerd shim process
.:/home/kevin_simons$ ps -aux | grep 3a2178477417
root     11587  0.0  0.0<PHONE_NUMBER>4 ?        Sl   Nov01   0:44 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 3a2178477417e2346548c23dd78a085b16ce0b333dad1943ef87ed581f2c6af9 -address /run/containerd/containerd.sock
root     21193  0.0  0.0 1174584 10388 ?       Sl   05:28   0:00 runc --root /var/run/docker/runtime-runc/moby --log /run/containerd/io.containerd.runtime.v2.task/moby/3a2178477417e2346548c23dd78a085b16ce0b333dad1943ef87ed581f2c6af9/log.json --log-format json exec --process /tmp/runc-process119335193 --detach --pid-file /run/containerd/io.containerd.runtime.v2.task/moby/3a2178477417e2346548c23dd78a085b16ce0b333dad1943ef87ed581f2c6af9/3a7ac34beeea2c994a83dd8677b15b9c90045bf1d193f484b7ccf8d6106066e1.pid 3a2178477417e2346548c23dd78a085b16ce0b333dad1943ef87ed581f2c6af9
root     32682  0.0  0.0 119424   924 pts/0    S+   19:18   0:00 grep --color=auto 3a2178477417

:/home/kevin_simons$ strace -s 800 -T -y -yy -f -p 11587
strace: Process 11587 attached with 12 threads
[pid 21281] epoll_pwait(5<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 11668] futex(0xc000080d48, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 21281] <... epoll_pwait resumed> [], 128, 0, NULL, 194962698) = 0 <0.000032>
[pid 21281] epoll_pwait(5<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 11597] futex(0xc000080948, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11596] futex(0xd26e60, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11595] futex(0xcf8658, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000012>
[pid 11594] futex(0xc000080548, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11595] epoll_wait(9<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 11593] futex(0xd26d18, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11592] futex(0xc000080148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11591] futex(0xc000042948, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11590] epoll_wait(10<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 11589] restart_syscall(<... resuming interrupted epoll_wait ...> <unfinished ...>
[pid 11587] futex(0xcf7a68, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11589] <... restart_syscall resumed> ) = -1 EAGAIN (Resource temporarily unavailable) <0.000021>
[pid 11589] futex(0xc000080d48, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 11668] <... futex resumed> )       = 0 <0.000443>
[pid 11589] <... futex resumed> )       = 1 <0.000036>
[pid 11668] sched_yield( <unfinished ...>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>
[pid 11668] <... sched_yield resumed> ) = 0 <0.000027>
[pid 11668] futex(0xcf6dc0, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000014>
[pid 11668] futex(0xc000080d48, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 11589] <... nanosleep resumed> NULL) = 0 <0.000093>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000090>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000092>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000092>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000092>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000092>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000095>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
[pid 11589] nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 <0.000091>
...

That then loops through the FUTEX_WAIT_PRIVATE calls indefinitely.
Generating stack trace of docker which generates an extremely large file
.:/home/kevin_simons$ kill -SIGUSR1 $(pidof dockerd)

.:/home/kevin_simons$ journalctl -u docker.service -r
Nov 02 19:22:15 ip-10-32-134-101.ec2.internal dockerd[7078]: time="2022-11-02T19:22:15.973566811Z" level=info msg="goroutine stacks written to /var/run/docker/goroutine-stacks-2022-11-02T192215Z.log"
...

.:/home/kevin_simons$ ls -al /var/run/docker/goroutine-stacks-2022-11-02T192215Z.log
-rw-r--r-- 1 root root 10306382 Nov  2 19:22 /var/run/docker/goroutine-stacks-2022-11-02T192215Z.log

Inside the stack trace we see what seems like thousands of goroutines similar to
goroutine 9403905 [semacquire, 528 minutes]:
sync.runtime_SemacquireMutex(0xc00103f204, 0x0, 0x1)
        /usr/lib/golang/src/runtime/sema.go:71 +0x49
sync.(*Mutex).lockSlow(0xc00103f200)
        /usr/lib/golang/src/sync/mutex.go:138 +0x105
sync.(*Mutex).Lock(...)
        /usr/lib/golang/src/sync/mutex.go:81
github.com/docker/docker/daemon.(*Daemon).ContainerInspectCurrent(0xc00000c1e0, 0xc012072016, 0x40, 0x0, 0x1, 0xc019970018, 0xc0096c22e0)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/daemon/inspect.go:40 +0xa30
github.com/docker/docker/daemon.(*Daemon).ContainerInspect(0xc00000c1e0, 0xc012072016, 0x40, 0x0, 0xc012072006, 0x4, 0xc014d321b0, 0x562e8d0ca91d, 0x7f20140ff498, 0x8)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/daemon/inspect.go:29 +0x11b
github.com/docker/docker/api/server/router/container.(*containerRouter).getContainersByName(0xc000c2f480, 0x562e8f7ab640, 0xc0127a6f30, 0x562e8f79b680, 0xc00d82c2a0, 0xc01a318700, 0xc0127a6e70, 0xc00bb4c801, 0xc01227f4a0)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/api/server/router/container/inspect.go:15 +0x116
github.com/docker/docker/api/server/middleware.ExperimentalMiddleware.WrapHandler.func1(0x562e8f7ab640, 0xc0127a6f30, 0x562e8f79b680, 0xc00d82c2a0, 0xc01a318700, 0xc0127a6e70, 0x562e8f7ab640, 0xc0127a6f30)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/api/server/middleware/experimental.go:26 +0x17d
github.com/docker/docker/api/server/middleware.VersionMiddleware.WrapHandler.func1(0x562e8f7ab640, 0xc0127a6f00, 0x562e8f79b680, 0xc00d82c2a0, 0xc01a318700, 0xc0127a6e70, 0x203002, 0x203002)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/api/server/middleware/version.go:62 +0x617
github.com/docker/docker/pkg/authorization.(*Middleware).WrapHandler.func1(0x562e8f7ab640, 0xc0127a6f00, 0x562e8f79b680, 0xc00d82c2a0, 0xc01a318700, 0xc0127a6e70, 0x562e8f7ab640, 0xc0127a6f00)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/pkg/authorization/middleware.go:59 +0x822
github.com/docker/docker/api/server.(*Server).makeHTTPHandler.func1(0x562e8f79b680, 0xc00d82c2a0, 0xc01a318600)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/api/server/server.go:141 +0x258
net/http.HandlerFunc.ServeHTTP(0xc00092eda0, 0x562e8f79b680, 0xc00d82c2a0, 0xc01a318600)
        /usr/lib/golang/src/net/http/server.go:2042 +0x46
github.com/docker/docker/vendor/github.com/gorilla/mux.(*Router).ServeHTTP(0xc000bcea80, 0x562e8f79b680, 0xc00d82c2a0, 0xc01a318400)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/vendor/github.com/gorilla/mux/mux.go:210 +0xd3
net/http.serverHandler.ServeHTTP(0xc0001fa000, 0x562e8f79b680, 0xc00d82c2a0, 0xc01a318400)
        /usr/lib/golang/src/net/http/server.go:2843 +0xa5
net/http.(*conn).serve(0xc014baa140, 0x562e8f7ab580, 0xc00cb5e980)
        /usr/lib/golang/src/net/http/server.go:1925 +0x8ad
created by net/http.(*Server).Serve
        /usr/lib/golang/src/net/http/server.go:2969 +0x36c

The oldest of these semacquire for this was 834 minutes so we grabbed the other goroutines in that dump that were at that time
.:/home/kevin_simons$ cat /var/run/docker/goroutine-stacks-2022-11-02T192215Z.log | grep goroutine | grep -v semacquire | grep 834
goroutine 9233430 [sync.Cond.Wait, 834 minutes]:
goroutine 9233295 [sync.Cond.Wait, 834 minutes]:
goroutine 9233431 [sync.Cond.Wait, 834 minutes]:
goroutine 9233297 [select, 834 minutes]:
goroutine 9233465 [select, 834 minutes]:
goroutine 9233462 [select, 834 minutes]:
goroutine 9233464 [select, 834 minutes]:
goroutine 9233427 [select, 834 minutes]:
goroutine 9233432 [select, 834 minutes]:
goroutine 9233461 [syscall, 834 minutes]:
goroutine 9233463 [syscall, 834 minutes]:
goroutine 9233296 [sync.Cond.Wait, 834 minutes]:
goroutine 9233460 [select, 834 minutes]:
goroutine 9233408 [select, 834 minutes]:

The two syscall routines there show this
.:/home/kevin_simons$ cat /var/run/docker/goroutine-stacks-2022-11-02T192215Z.log | grep -A 20 "syscall, 834"
goroutine 9233461 [syscall, 834 minutes]:
syscall.Syscall6(0x101, 0xffffffffffffff9c, 0xc00277e140, 0x80000, 0x0, 0x0, 0x0, 0x2eb4037, 0x1, 0x11c0)
        /usr/lib/golang/src/syscall/asm_linux_amd64.s:41 +0x5
syscall.openat(0xffffffffffffff9c, 0xc00277e120, 0x11, 0x80000, 0x0, 0x0, 0x0, 0x0)
        /usr/lib/golang/src/syscall/zsyscall_linux_amd64.go:68 +0xc8
syscall.Open(...)
        /usr/lib/golang/src/syscall/syscall_linux.go:152
os.openFileNolog(0xc00277e120, 0x11, 0x0, 0x0, 0x1723ad5a3241959c, 0xc002fc8fa0, 0x562e8d52c24a)
        /usr/lib/golang/src/os/file_unix.go:200 +0x91
os.OpenFile(0xc00277e120, 0x11, 0x0, 0x0, 0x0, 0xc00562fdf8, 0xc00562fce0)
        /usr/lib/golang/src/os/file.go:327 +0x65
github.com/docker/docker/vendor/github.com/containerd/fifo.openFifo.func2(0x0, 0xc002300740, 0x0, 0xc003dc13e0, 0x562e8f7ab580, 0xc002300700)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/vendor/github.com/containerd/fifo/fifo.go:130 +0x371
created by github.com/docker/docker/vendor/github.com/containerd/fifo.openFifo
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/vendor/github.com/containerd/fifo/fifo.go:123 +0x265

--
goroutine 9233463 [syscall, 834 minutes]:
syscall.Syscall6(0x101, 0xffffffffffffff9c, 0xc000b4c6a0, 0x80000, 0x0, 0x0, 0x0, 0x2eb4038, 0x1, 0x11c0)
        /usr/lib/golang/src/syscall/asm_linux_amd64.s:41 +0x5
syscall.openat(0xffffffffffffff9c, 0xc000b4c360, 0x11, 0x80000, 0x0, 0x0, 0x0, 0x0)
        /usr/lib/golang/src/syscall/zsyscall_linux_amd64.go:68 +0xc8
syscall.Open(...)
        /usr/lib/golang/src/syscall/syscall_linux.go:152
os.openFileNolog(0xc000b4c360, 0x11, 0x0, 0xc000000000, 0xc002011410, 0xc00275ed80, 0xc00499bfb0)
        /usr/lib/golang/src/os/file_unix.go:200 +0x91
os.OpenFile(0xc000b4c360, 0x11, 0x0, 0x0, 0x0, 0x2000100000000, 0xc003043aa0)
        /usr/lib/golang/src/os/file.go:327 +0x65
github.com/docker/docker/vendor/github.com/containerd/fifo.openFifo.func2(0x0, 0xc002300780, 0x0, 0xc003dc14a0, 0x562e8f7ab580, 0xc002300700)
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/vendor/github.com/containerd/fifo/fifo.go:130 +0x371
created by github.com/docker/docker/vendor/github.com/containerd/fifo.openFifo
        /builddir/build/BUILD/docker-20.10.7-5.amzn2/src/github.com/docker/docker/vendor/github.com/containerd/fifo/fifo.go:123 +0x265

As far as I found there was now way to display what file was actually being opened with that syscall.Open and this is where we discovered the kernel bump in our AMI and eventually to this issue and the corresponding comment in aws repo pinning the kernel version https://github.com/awslabs/amazon-eks-ami/blob/1e89a4483c5bd2c34fcdf89d625fbd56085d83cf/scripts/upgrade_kernel.sh#L16 .
In order to trigger this issue we've been executing a kubectl rollout restart ... of one of our daemonsets to tear down a pod on every node.
Hopefully some of this may be useful in tracking down the issue.

@kevinsimons-wf
I have been seeing similar issues. Also followed a similar debug process.
But I also have seen the issue happening without any container in a bad state.
In all cases tho (maybe you can check it out), before we start seeing the PLEG error we see a bunch of log lines containing the string fsHandler.go:119] failed to collect filesystem stats - rootDiskErr: could not stat . right after those PLEG error appears.
Finally (I have not been able to verify it is the cause, but it could make sense) this error seems to happen within under 10 minutes from a new network interface is added, see dmesg -T for lines such as :
[Tue Nov  1 17:55:16 2022] ena 0000:00:08.0 eth3: Local page cache is disabled for less than 16 channels

It could happen that there was a blip on the network that caused kubelet to fail reading the disk and entered in this bad state. At the same time, the same blip could be causing other processes to enter in bad state (I actually had a bunch of aws-node subprocesses in Z state)
Same as you, hopefully this might help solve the issue...

AmazonLinux has released kernel 5.4.219-126.411.amzn2 yesterday, which we expect to solve the issues described here. We've tested it with our reproduction of the issue, and it seems to work. To solve this issue, you can do one of the following:

If you build a custom AMI, build a new AMI with the latest commit (or at least exclude the commit pinning the kernel version) and you should get the latest kernel.
EKS is working on publishing new AMIs, which will be release version v20221103 or later. We will update this repo as soon as those AMIs are released. At the moment, it's looking like 11/7/22 is when they'll be available.
Lastly, you can manually upgrade the kernel on your nodes. If you're using release v20221101, you'll need to unpin the kernel. I don't recommend this approach unless it's very important that you get on the latest kernel.

The problem seems so widespread that AWS should issue an official statement. Can we expect something like that? I learned about this issue only from a support ticket and after some production clusters went down already.

FYI, updated mitigation recommendation above to call out that v20221101 is running on an older kernel version that doesn't have the problem described here.

The problem seems so widespread that AWS should issue an official statement. Can we expect something like that? I learned about this issue only from a support ticket and after some production clusters went down already.

Same here.....

Hi, I see that the patched kernel mentioned is available. @mmerkes When should the new ami release come out?

Hi, I see that the patched kernel mentioned is available. @mmerkes When should the new ami release come out?

is already out the new image ;)

The latest AMI doesn't have this kernel 5.4.219-126.411.amzn2.

Are there any release notes for kernel 5.4.219-126.411.amzn2?

5.4.219-126.411.amzn2 seems available with release v20221104

Doing a proper post incident review should be a standard procedure. I am negatively surprised that it is not taking place.

Sorry, I was OOTO, so wasn't able to update here. v20221104 was released with the latest kernel, 5.4.219-126.411.amzn2, which resolves this issue.
When issues like this happen, it is our standard practice to root cause the issue, mitigate and review our processes to avoid similar issues in the future. In this case, the process is ongoing. We have developed a test that reproduces this particular issue and have added that as part of our AMI release process. As for more details on the root cause, I'll post here if AmazonLinux has released anything with more details. In a nutshell, a commit on the kernel was causing some workloads to hang, which was reverted on the latest kernel.

I updated our clusters Tue night and things seemed fine, but today I'm seeing nodes flapping with NotReady state again with PLEG errors, and pods left in a Terminating state:
PLEG is not healthy: pleg was last seen active 8m16.90989123s ago; threshold is 3m0s
Kernel Version:             5.4.219-126.411.amzn2.x86_64
OS Image:                   Amazon Linux 2
Operating System:           linux
Architecture:               amd64
Container Runtime Version:  docker://20.10.17
Kubelet Version:            v1.22.12-eks-ba74326
Kube-Proxy Version:         v1.22.12-eks-ba74326

You could diagnose the previous issue by running ps a few times and seeing a runc init process that was hung.  Do you see that on your node?

Thanks for the quick reply. I didn't see those processes on my nodes. Today I installed an efs-csi driver update that was quickly updated to a new release today, perhaps that was causing my issues. I spun up all new nodes in my clusters and things seem stable now.


Translation of dataverse-previewers #17

This pull request is to request the translation of the dataverse-previewers . We have used the jquery.i18n library https://github.com/wikimedia/jquery.i18n which have a dual GPL / MIT license: wikimedia/jquery.i18n#136 .
This pull request is a copy of #18 due to changes in development branch ( #40 ).

Thanks @juancorr ! It's merged into develop.


Remove version: WilbertBerendsen.Frescobaldi version 3.2

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://sourceforge.net/projects/frescobaldi.mirror/files/v3.2/Frescobaldi.Setup.3.2.exe/download
OK
(Automated message - build 923)

Package still available.

Close with reason: Package still available.;


Potential null pointer reference

BN_STACK_pop() may cause a null pointer reference.
Fixes #19428

The proper fix is IMO to fix the bug in the testcase. I.e., put the BN_CTX_start right after the BN_CTX_new() call.

Yes, I see the same approach for other test cases, but the unclear addition still has the same problem. And I'm going to do it as is customary.

Please do not add merge commits. Use git rebase against fresh master branch instead.

Please do not add merge commits. Use git rebase against fresh master branch instead.

Sorry, Git rebase has been redone.

This pull request is ready to merge

Merged to master, 3.0, and 3.1 branches. Thank you for your contribution.


openexr_2: fix CVE-2021-3933, enable tests

Description of changes
Apply a patch for CVE-2021-3933 on openexr 2.x. Also, enable tests the same way they have been enabled in openexr 3.x.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

The current default is openexr_2: https://github.com/NixOS/nixpkgs/blob/2de862f1467fe5f89e2d6895b1e97fabc443cd14/pkgs/top-level/all-packages.nix#L23397. Many packages depend on openexr, so the first step in killing openexr_2 would be to move all those reverse dependency packages to openexr_3 one by one.
In a very quick test I see at least opencv and libjxl fail to build with openexr_3.

Hmm. I wonder why upstream haven't included this patch themselves, because they're supposedly still doing releases for the 2.x branch.

@risicle:

Oh wait, the last release was March 2022. That worries me further then, because I'm sure there have been other vulnerabilities since then.

I think most of the recent openexr CVEs  have been fixed in openexr 2.5.x with PRs https://github.com/AcademySoftwareFoundation/openexr/commit/4212416433a230334cef0ac122cb8d722746035d and  https://github.com/AcademySoftwareFoundation/openexr/pull/1040.
The only fixes I found missing from openexr 2.5.x is CVE-2021-3933 and CVE-2021-26945.
This PR is an attempt to patch CVE-2021-3933 in nixpkgs. As you wrote, CVE-2021-3933 has not been patched upstream in 2.5.x branch, so we might also not want to backport this fix in nixpkgs openexr_2. I'm fine either way, but wanted to raise this PR since I could not find any earlier discussion about  CVE-2021-3933 in nixpkgs.
The upstream fix for CVE-2021-26945 is in PR https://github.com/AcademySoftwareFoundation/openexr/pull/930, which I think, does not apply to openexr_2.

@ofborg build pkgsi686Linux.openexr
Fails too.

@risicle:

@ofborg build pkgsi686Linux.openexr
Fails too.

Thanks, I failed to notice that earlier. https://github.com/NixOS/nixpkgs/commit/7b78245076befdcc932b81c059db899f99f989a5 simply disables the tests on i686. In testing the sse enforcement from 3.x I see it

For 22.11 & 23.05 we probably want the patch without the test additions.

@risicle : backport for 23.05 without the test additions is in https://github.com/NixOS/nixpkgs/pull/236043.
Do you still want this for 22.11 also?

The tests seem to fail most of the time, with a timeout in OpenEXR.IlmImf.  When the package does successfully build for me, it still takes a long time, so maybe the timeout for that test just needs to be increased?

@alyssais :

The tests seem to fail most of the time, with a timeout in OpenEXR.IlmImf. When the package does successfully build for me, it still takes a long time, so maybe the timeout for that test just needs to be increased?

Below is an example test run from OfBorg / openexr_2, openexr_2.passthru.tests on x86_64-linux:
...
[100%] Built target IlmImfTest
running tests
check flags: SHELL=/nix/store/xfb3ykw9r5hpayd05sr0cizwadzq1d8q-bash-5.2-p15/bin/bash VERBOSE=y test
Running tests...
/nix/store/bnmxyb30n6b5fq1gj3f4jzwxf7z8b4ls-cmake-3.25.3/bin/ctest --force-new-ctest-process
Test project /build/source/build
   Start 1: IlmBase.Half
   Start 2: IlmBase.Iex
   Start 3: IlmBase.Imath
   Start 4: OpenEXR.IlmImf
   Start 5: OpenEXR.IlmImfUtil
1/5 Test #2: IlmBase.Iex ......................   Passed    0.00 sec
2/5 Test #1: IlmBase.Half .....................   Passed    1.11 sec
3/5 Test #3: IlmBase.Imath ....................   Passed    4.04 sec
4/5 Test #5: OpenEXR.IlmImfUtil ...............   Passed   31.02 sec
5/5 Test #4: OpenEXR.IlmImf ...................   Passed  337.72 sec
100% tests passed, 0 tests failed out of 5
Total Test time (real) = 337.73 sec
checkPhase completed in 5 minutes 38 seconds
...

Do you have example logs you could point me to from when the tests fail with a timeout?

Sure. On #240296 it's failed three times due to openexr.  Here's an example:
error: builder for '/nix/store/gk65p5cw1r60fc8cgn6syyd95mscq7fg-openexr-2.5.8.drv' failed with exit code 2;
       last 10 log lines:
       >
       >
       > 80% tests passed, 1 tests failed out of 5
       >
       > Total Test time (real) = 1501.89 sec
       >
       > The following tests FAILED:
       >          4 - OpenEXR.IlmImf (Timeout)
       > Errors while running CTest
       > make: *** [Makefile:71: test] Error 8
       For full logs, run 'nix log /nix/store/gk65p5cw1r60fc8cgn6syyd95mscq7fg-openexr-2.5.8.drv'.

I suspect the difference is that, in your example, OfBorg has been told to build openexr, so once it gets to that point, that's the only thing that machine is building.  Whereas in my example, it's building other things at the same time, so there'll be more load over all.  That matches my experience on my personal machine too, where every build of dependent packages I've done recently has failed due to openexr, but when I build it on its own, the problem goes away, and I can then finish the rest of my build with no probelm.

@alyssais :

I suspect the difference is that, in your example, OfBorg has been told to build openexr, so once it gets to that point, that's the only thing that machine is building. Whereas in my example, it's building other things at the same time, so there'll be more load over all. That matches my experience on my personal machine too, where every build of dependent packages I've done recently has failed due to openexr, but when I build it on its own, the problem goes away, and I can then finish the rest of my build with no probelm.

Here's an attempt to fix the problem by splitting the OpenEXR.IlmImf test into smaller parts: https://github.com/NixOS/nixpkgs/pull/240660


Suggestion: Code to text block or clipboard

Rather than creating an addon from scratch, I mainly want to "copy" my node tree into existing code.
Maybe something where the code starts from creating a new node_group datablock, and adds all the nodes and links rather than the full boilerplate and zip version. That way I can just insert the code to my addons where I know when it gets to it, it'll just create a copy of my node graph and then continue with what I need afterwards. I wouldn't even assign it to a modifier or anything either, I'd leave that up to the end user to integrate the code.

This would be super useful for my needs as well,
I'm trying to make Blender act a little like 'Houdini engine' for Unity, If I was able to rebuild a predesigned node network through python code supplied by unity, then I could avoid loading and unloading .blend files making the process easier to obscure from the end user.

Think this would be a good option to have.
The main reason it creates a whole add-on right now is to guarantee referenced assets (namely images right now) in the node network are properly included, but I could see cases where that's either unnecessary or unwanted behavior.
Shouldn't be too hard to implement; I'll try to get a chance to work on it in the next few weeks.
In the meantime, the outermost [name]_node_group() function in the generated init.py files handles all the logic for creating a node network, so copying this will do the trick. It is a bit of a pain to unzip the addon and do this manually since these can get pretty long. You'd also have to make sure it isn't loading images or setting their defaults, too, which you can see by searching for #load image [name] comments. I think those are the only issues you might come across though

Got a rough implementation of this right now over at #53. There's a couple complications with how to save the script, so I'd like to hear everyone's thoughts on how best to implement this.
https://github.com/BrendanParmer/NodeToPython/discussions/54


Refactor to increase reliance on dependency injection

Did some refactoring to increase the reliance on dependency injection. I changed a few constructors in order to be able to inject dependencies into the classes that required them.
There are no changes for the end user and this should be seamless.
However, this does opens up possibilities where we could configure Photino.Blazor's behavior with extension methods. For example, one could add wwwroot as an EmbeddedResource and have the file embedded in the dll instead of outputting them to the bin folder.
Please let me know if there's anything.
Cheers!

@MikeYeager Is there anything I can do to get this PR merged?
It opens the door to easily replacing the PhysicalFileProvider to something like the EmbeddedFileProvider by increasing the reliance on dependency injection for the internal components of Photino.Blazor.  In the future, we could also add more extension methods to configure Photino.Blazor's behavior.
Please review my PR and give me feedback if you think there's anything I can change and/or improve.
Thank you!

@tomlm Do you have some time to give this a once-over and do some testing? The changes look fine to us, but we're not in a position to do a lot of testing right now.

@MikeYeager @tomlm any updates on this?
I'd really like to build a one-file desktop app using Blazor. This PR is the first step in that direction. By increasing the reliance on DI, I can replace the PhysicalFileProvider with the EmbeddedFileProvider. This would allow be to bundle the wwwroot inside the app.

@whyvra We are getting close to releasing an update to Photino.NET that makes use of the Kestrel (ASP.NET Core) bundled web server. It's wired up to allow you to embed files as resources AND/OR include them as copied files. There is a little bit more description in issue #97 in Photino.NET (https://github.com/tryphotino/photino.NET/issues/97). It doesn't use dependency injection, but it makes it much easier to use the already available local web server to serve embedded resources and/or local files. Does this solve your problem?

@MikeYeager Bundling a whole web server seems a bit excessive for my use case. This PR makes no change to the underlying functionality of Photino.Blazor, it just modifies classes constructors to increase the reliance of DI which would allow to introduce things like extension method to modify Photino.Blazor's behavior.
This PR doesn't have any of those extensions methods. I'm more than fine maintaining my own set of extension methods (or submitting a PR in the future).But we need to fix the classes that generate instance of other classes in their constructors in order for that to happen

@whyvra I think we're trying to address a couple of different issues at once. I was pointing out that your example scenario can now handled differently if that's your goal. We're not actually bundling anything as the ASP.NET web server is already part of .NET. We're just taking advantage of it. Separately, we're still concerned that this is a breaking change. We'd like to see a default constructor that calls a backwards compatible initialization method and have someone do some testing to ensure this pull request doesn't break existing apps. While we're generally in favor of your approach, we don't feel comfortable introducing it without ensuring backward compatibility. Thanks for your contribution. There is a lot of good work in there.

@MikeYeager Is there anything you'd like for me to add to my PR?

Hi @MikeYeager
I removed the constructor I had added to PhotinoBlazorApp, thus restoring the default one. Instead, I use the Initialize method to supply values to the properties via dependency injection as the Initialize method receives a IServiceProvider parameter. I also rebased my debug branch against photino.Blazor/debug branch since you guys had a bunch of changes.
I've tested both sample apps on Windows and Linux and they both work as they did previously. I have a small Photino/Blazor app that I tested against too and it works great too, can even use DI to replace the PhysicalFileProvider with a EmbeddedFileProvider.
Let me know what you think,
Cheers!

Hello @whyvra ,
We have checked the PR and figured it's a good feature implementation. We merged it into our debug branch.


syntastic breaks command-t

It appears that the default setting g:syntastic_echo_current_error=1 breaks command-t plugin. In particular, when entering a search criteria this setting clears command prompt area which make it impossible to see the entered search string.
My suggestion is to have this setting disabled by default, not to mention obvious performance implications, considering that it does that on every cursor movement no matter which buffer/filetype you are working with at the moment.

Just pushed a fix for this here a24bf027cc8b4d5ca99a50a54bc0af912408f728.
I have considered making it use cursorhold instead of cursormoved, but thought i'd wait and see how it performed and whether it was annoying. Have you noticed any performance issues?
It could be optimized with a couple of if statements, but really the function is doing very little and you would have to have lots of errors before it started taking up any real time.
If you have any more issues with this then just comment back here and ill reopen :)


Can not squeeze dim[3], expected a dimension of 1, got 2 for 'generator/Squeeze'

Hi, when I run the generate,
.sg_upconv(dim=2, act='sigmoid', bn=False).sg_squeeze()
there is a error:
ValueError: Can not squeeze dim[3], expected a dimension of 1, got 2 for 'generator/Squeeze' (op: 'Squeeze') with input shapes: [?,384,1,2].
what is it?
thank you.

@lyzhangjm  Hi, did you solve this problem? I met the same error here.

@YazhouZhang0709 ， I have not solved the problem. I don't know the reason.

@YazhouZhang0709 Hi,I have also met this problem.Do you have any method to solve this？

I am also getting this issue after a successful train on 100k rows.
Traceback (most recent call last):
  File "generate.py", line 55, in <module>
    .sg_upconv(dim=2, act='sigmoid', bn=False).sg_squeeze())
  File "/usr/local/lib/python2.7/dist-packages/sugartensor/sg_main.py", line 170, in wrapper
    out = func(tensor, tf.sg_opt(kwargs))
  File "/usr/local/lib/python2.7/dist-packages/sugartensor/sg_transform.py", line 119, in sg_squeeze
    return tf.squeeze(tensor, opt.axis, name=opt.name)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/array_ops.py", line 2394, in squeeze
    return gen_array_ops._squeeze(input, axis, name)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/gen_array_ops.py", line 5202, in _squeeze
    "Squeeze", input=input, squeeze_dims=squeeze_dims, name=name)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/op_def_library.py", line 787, in _apply_op_helper
    op_def=op_def)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 2958, in create_op
    set_shapes_for_outputs(ret)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 2209, in set_shapes_for_outputs
    shapes = shape_func(op)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 2159, in call_with_requiring
    return call_cpp_shape_fn(op, require_shape_fn=True)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/common_shapes.py", line 627, in call_cpp_shape_fn
    require_shape_fn)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/common_shapes.py", line 691, in _call_cpp_shape_fn_impl
    raise ValueError(err.message)
ValueError: Can not squeeze dim[3], expected a dimension of 1, got 2 for 'generator/Squeeze' (op: 'Squeeze') with input shapes: [?,384,1,2].

Hi, did anybody solves that ?
Stop at same error with tensorflow 1.0.0 as sugartensor requirement.
That's a real bag of bones between variable parameters values and hard-coded values...
@buriburisuri Any help on that ?

Well, found that to make it work but should be used with caution !!

raise ValueError(err.message)
ValueError: Can not squeeze dim[2], expected a dimension of 1, got 150 for 'QAModel/Squeeze_300' (op: 'Squeeze') with input shapes: [?,300,150].

@lyzhangjm Hi, did you solve this problem? I met the same error here.

<EMAIL_ADDRESS>微信：loveanshen  QQ:519838354

I met the same problem, I don't know how to solve it.

<EMAIL_ADDRESS>微信：loveanshen  QQ:519838354

avez-vous résolu ce problème? J'ai rencontré la même erreur ici
tensorflow.python.framework.errors_impl.InvalidArgumentError: Can not squeeze dim[3], expected a dimension of 1, got 3


Add Python 3.9 to supported versions in setup.py

This PR updates our setup.py to correctly indicate support for Python 3.9 which we're already using as target version in our test pipeline.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.061%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2840

Relevant Lines:
2926

💛  - Coveralls


Type inference tests mesolve

Same as PR #191 but with mesolve

I close this PR since this also includes changes from the #191. Once it will be merged, I will make again a PR


TypeError: undefined when using memberDecl on Integer or Float

class Integer`.memberDeclarations<ValueDeclaration>()

complains with TypeError: undefined is not an object.
Works for String.

Firefox tells us a bit more:

_mdl is undefined

gavin suggested `Integer`.getAttributes<Integer>as a workaround.

To be clear: this bug only affects JS. The code works correctly on the JVM.

Done.


Update vagrant integration and documentation

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4369/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4370/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4371/
Test PASSed.

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.0 please


[WIP] [branch-2.0] Persist meta when txn is committed/published

What type of PR is this：

[ ] bug
[ ] feature
[x] enhancement
[ ] others

Which issues of this PR fixes ：

Fixes #3140
Problem Summary(Required) ：

Flush the WAL of RocksDB after saving the meta. There are two flush operations during load.
One is the commit, and the other is the publish. To alleviate the I/O operations, we batch the flush operations.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.15 out of 17 committers have signed the CLA.:white_check_mark: kangkaisen:white_check_mark: ZiheLiu:white_check_mark: Astralidea:white_check_mark: trueeyu:white_check_mark: decster:white_check_mark: sevev:white_check_mark: stdpain:white_check_mark: Youngwb:white_check_mark: meegoo:white_check_mark: laotan332:white_check_mark: rickif:white_check_mark: mofeiatwork:white_check_mark: Seaven:white_check_mark: ABingHuang:white_check_mark: Linkerist:x: gengjun-git:x: mergify[bot]gengjun-git seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Partially incorrect eligibility criteria

Article claims that a MCA agreement fulfills the eligibility criteria for being able to request a host quota for Azure VMware Solution. However, after running into errors setting up and contacting Microsoft support, we discovered that this is not the case. Only CSP and EA accounts are eligible to request host quotas for Azure VMware Solution.

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

ID: 39368db1-a35c-2b2d-1752-4ef57c2290f7
Version Independent ID: 2d3ab019-e924-19c8-c830-1db67ec8ef68
Content: Request host quota for Azure VMware Solution - Azure VMware Solution
Content Source: articles/azure-vmware/request-host-quota-azure-vmware-solution.md
Service: azure-vmware
GitHub Login: @jjaygbay1
Microsoft Alias: jacobjaygbay

@BillysCoolJob
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@jjaygbay1
Can you please check and add your comments on this doc update request as applicable.

Hi guys, I would like to ask to keep this open for clarification, especially based on all the other feedback we've been getting from the Sales and Support teams for Azure. Plus this screenshot:

I did confirm that our current agreement is an MCA agreement.


Validation fuzz

Hi,
I have some trouble with one of my projects and I try to find out what went wrong, as I only used mobie-python to generate it and it now does not validate any longer.
One big issue is that the output of the validation is not very helpful. It spits out the entire schema cluttering the STDOUT and throws an error only stating what went wrong. But is missing the crucial information where (which view/source etc.) the error occurs.
File ".../jsonschema/validators.py", line 1121, in validate
    raise error
jsonschema.exceptions.ValidationError: Additional properties are not allowed ('name' was unexpected)

Failed validating 'additionalProperties' in schema['properties']['views']['properties']['default']:
    {'$id': 'https://raw.githubusercontent.com/mobie/mobie.github.io/master/schema/view.schema.json',
     '$schema': 'http://json-schema.org/draft-07/schema',
     'additionalProperties': False,
     'definitions': {'additionalTables': {'description': 'Additional '
                                                         'tables to load '
                                                         'for this '
                                                         'display. This '
                                                         'only needs to be '
...

and hundreds of more lines of schema.
Is it possible to change the output such that it provides clues on where the problem is (i.e. where this suspicious extra name can be found?

These error messages are generated by the jsonschema library: https://github.com/python-jsonschema/jsonschema
So I only have limited control over the validation error options. I haven't really looked into whether there they provide a way to simplify the validation messages. If you find one I am happy to adopt it here. If not you would need to raise the issue in the jsonschema repo.

makes sense.
When you know what to look for  (this information On instance['views']['default']:) You can find it.
Can a JSON schema be nested (pulling content from other files)? Then maybe it would not display everything but only the relevant part of the schema... (like only from transformedGrid instead of the whole view schema)

and to complicate things, it seems that the CLI calls for mobie-python don´t pipe their STDOUT.
mobie.validate_project -i data > val.log

produces an empty file and still spits out everything.

produces an empty file and still spits out everything.

You have to pipe all output:
mobie.validate_project -i data > val.log 2>&1

(This writes both the output from std:out and std:err to the same stream)

Can a JSON schema be nested (pulling content from other files)? Then maybe it would not display everything but only the relevant part of the schema...

Yes, that should in principle be possible and would make sense to implement. (I am personally not able to do this in the foreseeable future, but would be happy to provide pointers if you want to give it a try).


Continuous high CPU, Team Explorer flashing when opening FSharp solution from Github

VS2017 15.4.0 P2 + latest nightlies FSharp.
When opening a new copy through Git (Team Explorer > Clone) then opening FSharp.sln (which will partially fail, needs to be build from cmd line first), the Team Explorer will start flashing and VS2017 and MSBuild go nuts:
Flashing Team Explorer

** High CPU**

Repro steps

Open Team Explorer, select Git Clone, enter VisualFSharp Git repo
Open FSharp.sln
Go back to Team Explorer
Behavior as shown

Expected behavior
No flashing expected. The high CPU is perhaps expected, not sure.
Actual behavior
Flashing as in the video. High CPU for about 1-2 min (I didn't keep track). Then the CPU stopped and the flashing stopped.
Known workarounds
Wait it out.
Related information
VS 2017 v15.4.0 Preview 2 on Windows 7, all updates installed.
Not sure this is "normal" or "expected" behavior. Not sure this is related to the F# repo, or a VS2017 bug. And I haven't tested this in older VS's or RTM's.

I don't think it's related to VFT. BTW, why do you use Team Explorer? I find the UI and performance equally terrible. The best VCS UI/integration I've ever seen is the Rider's (IDEA) one.

@vasily-kirichenko, thanks for chiming in :). I didn't quite think it through, and on any other project I stay away from Team Explorer. But I figured, this is an MS prj by MS people (and a lot of volunteers), so let's stick to the toolchain they offer. It somehow seemed to make sense.
I just saw that this may be a known issue with VS20xx, because NCrunch (I am basically trying to run the unit tests with it) reports a warning on using Git with VS, in essence it says: don't use Git in VS!:

The Microsoft Git Provider has been detected as resident in the VS IDE, and this solution is part of a large git repository containing many entries.
The MS Git Provider has a performance issue that causes it to constantly re-scan the entire repository when file system changes are detected anywhere underneath the repository root or in nested directories.  This problem exists regardless of how Git is configured with .gitignore files, and is responsible for high CPU consumption in the IDE on solutions with large Git repositories.
Because NCrunch often updates files within its own cache directory (_NCrunch_SOLUTIONNAME), it can act as a continuous trigger for this performance problem.
If you are not actively using the Microsoft Git Provider, it is strongly recommended that you remove it from your system.  It is possible to disable this extension through Visual Studio's 'Tools->Options-Source Control' setting, but the extension very often re-enables itself silently at a later date.  To permanently remove this extension, see https://stackoverflow.com/questions/22459959/how-do-you-remove-microsoft-git-provider#23512676

wow. Sorry if I was advertising Rider too aggressively, I just love its VCS integration too much :)

wow. Sorry if I was advertising Rider too aggressively, I just love its VCS integration too much :)

It's definitely ok to talk about other F# IDEs and their merits in this repo - partly because it's not just the Visual F# IDE tools - it's also the repo of the F# compiler and compiler service, which form part of these IDEs. And partly because it's interesting and helpful to learn what other IDEs do.

wow. Sorry if I was advertising Rider too aggressively, I just love its VCS integration too much :)

@vasily-kirichenko: not to me the comment I wrote was about Git-integration of VS, not Rider. I don't think I have used Rider yet, unless unconsciously perhaps. So your comment came as an eye-opener to me :).

But I figured, this is an MS prj by MS people (and a lot of volunteers), so let's stick to the toolchain they offer. It somehow seemed to make sense.

@vasily-kirichenko, rereading my own comment it looks rather derisive, it wasn't meant that way, my apologies. I'm just starting out getting test coverage working and I figured, let's stick to the defaults given by the instructions in DEVGUIDE.md, before getting more adventurous and trying it with other tools.
Certainly, I didn't mean to suggest this project may only be used with MS tools, on the contrary ;), your input is very valuable to me.

Btw, I think I ought to close this thread, as this is an issue caused by the GIT provider or Visual Studio and has nothing to do with Visual F# tools.


Support both Pan or LongPress gesture. Support hook up gestures from any UIView in your UITableViewCell.

Modify the gesture handling to support both Pan or LongPress.
Modify the gesture to support binding to any UIView. It is handy to hook up an UIView in your cell.
Add missing framework in the sample project.
Modify the example project to fit the new way to setup the gestures.
Fix the position calculation of dragging view.

Can we take action and make a new PodSpec? There seem to be 6 pending pull requests, yet no changes in 2 years...


As a Maker, I need the option to identify myself to prospective takers if I think my reputation increases the liklihood of bounty being taken.

https://github.com/nostr-protocol/nips/blob/master/39.md
^^ we should be using this nip


Generate types for event logging in the JSON ABI

Closes https://github.com/FuelLabs/sway/issues/2130

[ ] Support generics: keep track of an initial_type_id or just collect TypeArgument.
[ ] Clean up the collection of logged type IDs.
[ ] IR instruction for logging - takes value and a type_id
[ ] Handle the new IR instruction in codegen

Closing in favour of https://github.com/FuelLabs/sway/pull/2689


Signed mismatch for intrinsics?

Hi,
I noticed that the nvptx repo was using wrapping_add, which was curious. In looking into it, I noticed that the type of the intrinsics seems to differ from what the CUDA guide states. Is this intentional?
http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#built-in-variables

The LLVM definition use i32 so I'm sticking to that. If you are using C/C++ (and CUDA is C/C++ + some language extensions) I suppose it doesn't matter what LLVM (the backend) uses because the compiler will implicitly cast between integer types.

That makes sense. I'd assume that we're nowhere near 2,147,483,647 blocks so it probably doesn't matter right now for signed/unsigned.


Issue 770: NSThread.Priority tests fail on OSX

This issue is due to the fact that thread priorities can change. When setting a
thread priority, the system actually decides what the thread's priority will be.
Because of this, using a hard equal in the test will fail. The solution is to
check if the priority is within a certain acceptable margin. This was acceptable
on Windows before since Windows pigeon holes the thread priorities into certain
groups that can be counted on to return as a certain value.
Verified by running unit tests and passing.

:shipit:

:shipit:

:shipit:

:clock1:

:clock1:

#Fix 770


Auto-scheduling based on local sunrise/sunset

Right now it is already possible to set up any activation/deactivation hour you want.
Even this feature seams to me less used than many others.
Please vote to change my mind:
👍 - need auto-scheduling
👎 - don't need it

👍

I'm really missing this feature. Currently I manually update the time settings every few weeks to match the sunrise / sunset times.

Any thoughts on implementing this based on OS schedule like in macOS Auto Dark Mode?
It is proposed in #253

I'd like it to work with the OS night mode so that when the browser chrome changes to dark mode, the content does too. Scheduling separate from the OS seems like a nice addition afterwards


Support $search

This is a proposed special attribute that allows you to fuzzy match a property. Possibly even multiple properties and/or nested documents.
Suggested syntax:
name: {
  $search: ['alice', 'Alice', 'bo', /$bob/i]
}

Following similar syntax to our other special query filters, this would allow you to filter by a singular value, multiple values (treated like an or) and/or regular expressions directly.
Internally mongodb requires a $regex query but we can fairly easily build a singular regex from this array. Another internal construct that mongodb provides is $text so we might be able to use that for full text search.

See https://github.com/feathersjs/feathers/issues/334


Remove unneccessary AppsandFeaturesEntries * manifests/a/ArduinoSA/IDE/stable/2.0.3/ArduinoSA.IDE.stable.installer.yaml

Microsoft Reviewers: Open in CodeFlow

URL:
Invalid URI: The hostname could not be parsed.
(Automated message - build 899)


Icons corrupted

Hello i loaded the zip.file and extracted it and normal build it in unity but all icons are corrupted even if i reload it i can't use any icons.

Import the video player from the unitypackage. Do not install any other way, as Unity will break things.


Import allows duplicate root level folders

If you import a root level folder with the same name and lelve but different uuid, it will be added to the database.  This is due to the fact that the FK_FOLDER_ID column allows nulls.  There is a unique key on NAME, FK_FOLDER_ID to prevent duplicate folder names under the same parent, but if the parent folder is null, i.e. at root level then duplicates are allowed because it can't enforce uniqueness on nulls.
To recreate:

Export a root level folder from stroom
Crack open the zip and replace the uuid of that folder with a new one, rebuild the zip
Import the zip
Stroom will have two entries in the FOLDER table for that folder name at root level.

This is related to #442

Fixed in 5.0


Delete TS files in VS2013 Update 4 with TS1.4 is very slow

Delete 50 ts files at same time in VS 2013 is so slow, and the VS window is no response.

I think TS service is handle the file changes one by one in the UI thread.

We have completely rewrote this part as we moved to VS2015 to fix this issue. Porting the change to VS2013 would be expensive at this point. so resolving this as won't fix.


Dr doc refinements

Context
Demoing the DR process to the publish team identified some refinements and fixes that could be made to the DR process.
https://trello.com/c/wx5ad9MF
Changes proposed in this pull request

Remove dependency on output from one script to execute another, this maintains compatibility across Linux distributions
Replaces grep with awk to maintain compatibility across Linux distributions
Fixed incorrect file permissions introduced by WSL

Guidance to review

The solution was developed on a Windows machine running Ubuntu 20 in WSL.  It should tested on MacOS ideally or another distribution.  A minimal test would be:

execute the deploy-plan command documented in recreate-the-lost-postgres-database-instance
execute the commands in restore-data-from-nightly-backup.  This can be done against QA with agreement from the publish team or against the review app by replacing ${paas_env} on line 116 of the make file with pr-2651

Checklist

[x] Make sure all information from the Trello card is in here
[x] Attach to Trello card
[x] Rebased master
[x] Cleaned commit history
[x] Tested by running locally

 TT API: simulate data corruption


How to auto click?

I want to click button "Click here to continue" on http://oke.io/. How?

How would I make an Xpath for an autoclicker that would click this every 5 seconds?

Can you please export your configuration and send us on<EMAIL_ADDRESS>we will try to reproduce your issue and fix the same.


chore: add new tools using script

Description
Due to the disabled workflow for updating tools on the website, we are manually merging the new tools using the PRs.

@derberg this needs your approval to get merged on main.

/rtm

@akshatnema remember to next time not open PR from a branch in upstream

@derberg so I should make the PR from my forked repo?

yes, always


bundle (>=1.15.0) install fails

Hi, I've noticed that when I run bundle install with Gemfile including version 4.0.3
I receive the following error:
Downloading sass-rails-4.0.3 revealed dependencies not in the API or the lockfile (sass (~> 3.2.0)).
Either installing with --full-index or running bundle update sass-rails should fix the problem.
notice it happens only with bundler 1.15.0+

Hello @yairper,
Actually this seems more like a Bundler feature than any sort of bug. The error message tells you what to do ; you can try to run it with --full-index.
Anyway, this version of sass-rails is 3 years old so even though if that was something to fix on our side, these release series aren't supported anymore.
I'm giving this a close but thanks for reporting anyway !


Updated german translation

Addresses #306
Check if this PR fulfills these requirements:

[x] My changes respect the Kodi add-on development rules
[x] I have read the CONTRIBUTING document.
[x] I made sure there wasn't another one Pull Requests opened for the same update/change
[x] I have successfully tested my changes locally

Types of changes

[ ] New feature (non-breaking change which adds functionality)
[ ] Feature change (non-breaking change which change behaviour of an existing functionality)
[x] Improvement (non-breaking change which improve functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Updated translation, addresses #306

i wait to merge this,
there will be two other small changes soon
so you can directly include them

@CastagnaIT That's fine. I have updated it with the latest changes.

@CastagnaIT Merge conflicts resolved

thank you


Tags icon size mismatch issue

So, I was trying to customize the tags icons. I tried copying icons from Nerd Font's Cheat Sheet and pasting in config.def.h
However, after sudo make install and restarting DWM, I can see that the icons are smaller than the default one provided by you.
The default icon size is PERFECT. So, a reference to the steps you took to choose the icons would be nice.
My current fonts are:
JetBrainsMono Nerd Font
MaterialDesign Icons Desktop

can you show a sceeenshot?

Look at the third "spotify" tag icon
Step to reproduce:
Visit: Nerd Fonts cheat sheet
Search: Spotify
Copy: icon with class "nf-fa-spotify"
Paste in: config.def.h
rm -f config.h && sudo make install
restart dwm

Look at the third "spotify" tag icon
Step to reproduce:
Visit: Nerd Fonts cheat sheet
Search: Spotify
Copy: icon with class "nf-fa-spotify"
Paste in: config.def.h
rm -f config.h && sudo make install
restart dwm
EDIT: Closed by mistake!

Do other icons copied from nerdfonts look small too?

Unluckily 3-4 icons I have tried resulted the same. But copy pasting "chrome" icon was producing the same sized tag icon though.

idk about this, if u have a hidpi screen then make sure you set the DPI in xresources first


Missing command when using glitch extension

I was trying out the glitch extension which I think probably uses a custom virtual filesystem, and when I make any changes inside the default JS file then it shows "!!!MISSING: Command!!!` which I checked the VS Code logs and it seems to come from live share:

Verbose logs: live-share-logs.zip - though I don't think they include this
Product and Version [VS/VSCode]: SVCode
OS Version [macOS/Windows]: macOS
Live Share Extension Version: latest
Target Platform or Language [e.g. Node.js]: This is a node project, but it's definitely safe to call it non-traditional
Steps to Reproduce / Scenario:

Install glitch
Open the command palette - do "Glitch - New Project"
Open a JS file
Make a single edit

I'm going to close this for now since we haven't heard significant customer feedback for this. If this is something that folks would like to see us prioritize, please let us know by re-opening/commenting on this bug. Thanks!


Vercel can't find the module "@vercel/postgres"

Here's the log saying that Vercel can't import Postgres:

Here are my dependencies in my package.json file:

Here's the command that I'm using to import it:

Did you get any help on this? I am going through the same problem.

Sadly Vercel deleted the deployment that had the error, so I'm not entirely sure what the problem was in the first place. But I do remember that I got it working.

It might have had something to do with making sure this is set to "Other." I changed it to Next as I switched over since I'd like a website here, too. However, I did get it working with Node, I just can't remember how... sorry