sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Pod quota is not released in time when node lost
Labels: kind/bug,sig/scheduling,sig/api-machinery,triage/accepted

### What happened?

when a node lost, let pod stuck terminating. pod.DeletionTimestamp = deleting time + pod.DeletionGracePeriodSeconds. it not need to add pod.DeletionGracePeriodSeconds again.

https://github.com/kubernetes/kubernetes/blob/36dd5f2846a6003d1b346969183270440f37b190/pkg/quota/v1/evaluator/core/pods.go#L467

i test in k8s 1.22.9
<pre>
08:21:33.173082       1 taint_manager.go:106] "NoExecuteTaintManager is deleting pod" pod="a495ebdf75df94cfdac8b8ab695c3640c/mysonarqube-6b76965c4d-4k4vz"

{TypeMeta:{Kind: APIVersion:} ObjectMeta:{Name:mysonarqube-6b76965c4d-4k4vz GenerateName:mysonarqube-6b76965c4d- Namespace:a495ebdf75df94cfdac8b8ab695c3640c SelfLink: UID:d93f3540-a166-44ca-8f98-10f97acb93a1 ResourceVersion:20185907 Generation:0 CreationTimestamp:2022-10-21 01:30:04 +0000 UTC DeletionTimestamp:2022-10-21 08:22:03 +0000 UTC DeletionGracePeriodSeconds:0xc0018d1a58
</pre>

### What did you expect to happen?

after the pod.DeletionTimestamp time, the pod quota released

### How can we reproduce it (as minimally and precisely as possible)?

1. create resourcequotas with limit 2c4g in a namespace
2. create deployment with 2c4g limits in namespace, scheduler to node-A and create success
3. stop the kubelet service in node-A
4. wait the node not ready and pod terminating
5. when pod is terminating , it will not be create a new pod, can find creating failure event because the quotas is limits

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
[root@nodeb1 ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.9", GitCommit:"76a2e07c5d0a8576421ebf2496f7516e5175fb9e", GitTreeState:"clean", BuildDate:"2022-09-01T02:23:39Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.9-6+b94cd2e055bf05-dirty", GitCommit:"b94cd2e055bf0589e9056ff235b4c760042acd66", GitTreeState:"dirty", BuildDate:"2022-09-29T12:59:35Z", GoVersion:"go1.17.7", Compiler:"gc", Platform:"linux/amd64"}

```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
[root@nodeb1 ~]# uname -a
Linux nodeb1 3.10.0-957.10.4.el7.x86_64 #1 SMP Wed Oct 21 09:27:12 CST 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@nodeb1 ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
```

</details>


### Install tools

<details>
kubespary
</details>


### Container runtime (CRI) and version (if applicable)

<details>
containerd
</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>
calico
</details>
Repository: stable-diffusion-webui
Issue: [Feature Request]: Include Onnx Pipeline + DirectML for Windows AMD card users (Img2Img and Inpainting are working - Diffusers 0.6.0)
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

As of Diffusers 0.6.0 the Diffusers Onnx Pipeline Supports Txt2Img, Img2Img and Inpainting for AMD cards using DirectML
Would it be possible to include the Onnx Pipeline now that Img2Img and Inpainting are working?

- OnnxStableDiffusionPipeline
- OnnxStableDiffusionImg2ImgPipeline
- OnnxStableDiffusionInpaintPipeline

Onnx Pipeline Supports Txt2Img, Img2Img and Inpainting
This process works on older AMD cards.

### Proposed workflow

1. On windows systems with older AMD cards, Onnx Pipeline is set as primary pipe or an option to use in image generation.
2. During install the following are downloaded and applied:

```bash
pip install diffusers
pip install transformers
pip install onnxruntime
pip install onnx
pip install torch
pip install onnxruntime-directml --force-reinstall
git clone https://huggingface.co/runwayml/stable-diffusion-v1-5 --branch onnx --single-branch stable_diffusion_onnx
git clone https://huggingface.co/runwayml/stable-diffusion-inpainting --branch onnx --single-branch stable_diffusion_onnx_inpainting
```

### Additional information

Examples: https://gist.github.com/averad/256c507baa3dcc9464203dc14610d674
Repository: PowerToys
Issue: Add ability to trigger PowerToys via command line
Labels: Idea-Enhancement,Needs-Triage

### Description of the new feature / enhancement

Most of the available PowerToys can only be triggered via a keyboard shortcut (e.g. Run, Text Extractor, Screen Ruler, Color Picker etc.)
Maybe an ability to run a command (i.e. `PowerToys.exe /activatePowerToy:ColorPicker`) (or maybe even an URL scheme à la `powetoys://ColorPicker`) to trigger the corresponding PowerToy would be beneficial.

### Scenario when this would be used?

Keyboard shortcuts are inconvenient for tablet users for example. In that case, users might want to create a shortcut which they can pin to the task bar that triggers the PowerToy they want.

### Supporting information

_No response_
Repository: PowerToys
Issue: [FancyZone] Multiple window layout profiles
Labels: Idea-Enhancement,Product-FancyZones

### Description of the new feature / enhancement

Sometimes you use different layouts in different situations. The most basic example would be a two window scenario vs a three window scenario. Win 11 has the feature, where you hover over the maximize button and it suggests some positions. FancyZone offers a more customizable and IMHO a more convenient way to achieve specific window layouts quickly. 
Wouldn't it be great, if you could have more than one layout to choose from?

I imagine creating multiple Layouts for different scenarios and cycling through layouts just by clicking RMB.

First click -> Layout one
Second click -> Layout two
.....
n'th click /ESC -> no Layout



### Scenario when this would be used?

see above

### Supporting information

_No response_
Repository: storybook
Issue: [Bug]: Storybook Docs Addon wrong displayName when using react's useContext+decorator
Labels: bug,needs triage

### Describe the bug

When using a decorator to give context to stories and then using the `code` feature, it displays the wrong displayName that it has been given to it by using `context.displayName = "Some Name"`  as the react docs say [here](https://reactjs.org/docs/context.html#contextdisplayname) and shows this (actually buggy):

![image](https://user-images.githubusercontent.com/12865914/197502643-1d5a8fc0-9a9f-4c01-8ca8-17c8cee6aaa7.png)
This for example doesn't happen on the React DevTools which display the correct DisplayName...
![image](https://user-images.githubusercontent.com/12865914/197503442-2abe90b9-b1d0-41de-88a7-7500c41d2b19.png)


If I _wrongly_ set the displayName this way: `context.Provider.displayName = 'SomeContext.Provider';` it does work. But this is not the way react works which makes TS to fail checks too...
![image](https://user-images.githubusercontent.com/12865914/197502988-6e7b9233-01c1-4100-9bd9-960666ff4586.png)



### To Reproduce

_No response_

### System

```shell
Using: "storybook": "^7.0.0-alpha.34"
Environment Info:

  System:
    OS: macOS 12.6
    CPU: (8) arm64 Apple M1 Pro
  Binaries:
    Node: 16.16.0 - ~/.nvm/versions/node/v16.16.0/bin/node
    Yarn: 1.22.18 - /opt/homebrew/bin/yarn
    npm: 8.11.0 - ~/.nvm/versions/node/v16.16.0/bin/npm
  Browsers:
    Chrome: 106.0.5249.119
    Firefox: 105.0.3
    Safari: 16.0
```


### Additional context

_No response_
Repository: go
Issue: time: Parsing of GMT+XX offsets is broken
Labels: help wanted,NeedsInvestigation

### What version of Go are you using (`go version`)?
1.19.1

### Does this issue reproduce with the latest release?
Yes

### What did you do?
https://go.dev/play/p/e5jcM1fIJm9?v=gotip (case 4 is the bug)

### What did you expect to see?
`GMT+2`, if it is parsed at all, ought to be treated the same as `+0200` (or `-0200`, according to Posix).

### What did you see instead?
It causes the time to be parsed as UTC, but be labelled as though an offset were applied.

When applying a known zone abbreviation the time is shifted at https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/time/format.go;l=1365;drc=85196fc982ead65ea56c377c2e381eabff329773;bpv=0;bpt=1 - it seems the same should be done at L1373.

However, this GMT+XX format parsing has a bunch of special-case code, supported by a single test, which checks the wrong input, and it's been this way forever without anyone noticing apparently. And as noted in https://github.com/golang/go/issues/40472, it's undocumented and interacts confusingly with the ISO/RFC822 style. Further, as noted in my case 3 above, the direction of the offset in this notation has conflicting conventions. So I'd suggest just removing this from the parser entirely.

(I encountered this only because I was reading the code looking for a way to detect my case 5 and turn it into an error - which sadly seems impossible in general without separately parsing zoneinfo.)
Repository: create-react-app
Issue: Security vulnerability SONATYPE-2021-0253 in a dependent package: jake 10.8.5
Labels: needs triage,issue: bug report

Security vulnerability SONATYPE-2021-0253 in a dependent package: `jake-10.8.5`

The jake package is vulnerable to OS Command Injection. The publish task in the publish_task.js file fails to sanitize jakefile contents before using them to construct a command that is executed via execSync(). An attacker with the ability to modify the jakefile.js file can exploit this vulnerability to execute arbitrary commands by creating tasks that contain a combination of shell meta-characters and commands and executing them via the affected fetchTags, getCurrentBranch and version functionalities.
Repository: godot
Issue: [4.0 beta3] editor cannot load assets(.png images) when i switch platform between Windows and Mac
Labels: bug,needs testing,topic:import

### Godot version

godot4.0 beta3

### System information

windows 11, Mac OS

### Issue description

**first,** on windows 11 platform.  I draged my images (.png) to the assets file, created some scenes with the image. and it works well, then I did git commit and git push.
**second,** switch to Mac OS platform, it shows that cannot load xxx images, I should delete the .import files  and load again. it worked then. finally git commit and git push again.
third, on windows11. git pull again. the image cannot be loaded again.


### Steps to reproduce

![image](https://user-images.githubusercontent.com/16015549/197525346-fabb7952-57a9-4327-aa4f-7f230b1dbe4f.png)

file status is not normal.
![image](https://user-images.githubusercontent.com/16015549/197525373-5ed511c7-f55a-4f54-bc78-14be4a44fc5e.png)


### Minimal reproduction project

_No response_
Repository: rust
Issue: Incorrect debug information generated for test binary for proc-macro crate
Labels: A-debuginfo,T-compiler,C-bug,A-proc-macros

Hello!

When investigating an issue with our code coverage reports at [firecracker](https://github.com/firecracker-microvm/firecracker), we noticed a lot `kcov` warning about the DWARF data contained in some binaries containing invalid mappings (e.g. line -> addr mapping that pointed into the middle of instructions). 

I tried this code:

On [this minimal test crate](https://github.com/roypat/break-kcov), run `cargo test --no-run` and extract the DWARF data using `elfread --debug-dump=decodedline`. When matching the output against `objdump -d`, notice how most of the debug information seems to reference non-existing code, or point to places outside of the `.text` segment. 

Alternatively, run `cargo kcov -- --verify --debug=4` (which internally executes `cargo test --no-run`) to see the errors `kcov` reports (culminating in a segmentation fault)

The debug information is correct if the `-Clink-dead-code` code-gen option is passed via `RUSTFLAGS`, however `RUSTFLAGS` are ignored by cargo for proc-macro crates during cross-compilation, which is how we encountered this error.

I expected to see this happen: the debug information to be correct

### Meta

<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-unknown-linux-gnu
release: 1.64.0
LLVM version: 14.0.6
```

I haphazardly tested some old versions of rustc (1.52, 1.54) and a recent nightly, all exhibiting the same behavior.
Repository: vscode
Issue: Use arm64 build agents to build arm64/armhf builds
Labels: engineering

We now have arm64 build agent pools. We could leverage them to run the followings jobs:

- Windows arm64
- Linux arm64
- Linux armhf
- Alpine arm64
Repository: stable-diffusion-webui
Issue: [Feature Request]: Allow setting the initial parameters of a new embedding, to correspond with a previous embedding (make a copy of it).
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Say there are two artists/objects with a very similar (but still distinct) art styles / appearances.

First, one creates an embedding for one of the artists/objects, then one trains it for a few dozens of hours, achieving the expected results.

Then, one wants another embedding for the second artist/object. Since it is similar to the previous artists, one would normally want to begin training from the spot the previous embedding ended, instead of starting from a vanilla initialization, in order to save time.

Currently, if you write the name of the first embedding in the "Initialization text" entry of the "Create Embedding" menu, it results in an embedding which, when used in a prompt, produces a vanilla result, rather than the result produced by the first trained embedding; training such embedding also begins from scratch (usually noise, since the vanilla model doesn't recognize the first embedding as a word) instead.

Currently, a workaround is, instead of using the "Create Embedding" menu, one copies the .pt file of the first embedding, and then renames the copy so it has the name of the new embedding. The problem is that this also inappropriately copies the metadata of the first embedding (such as the training steps count, or the name of the embedding as it is written in the contents of the file), and that might cause problems later on.

This feature could be implemented as an option to copy a previous embedding, but with a new name and appropriate metadata. Alternatively, the behavior of setting the "Initialization Text" of a new embedding to the name of a previous embedding could be changed, so it does what is intended as described in this feature request.

### Proposed workflow

1. Go to Train -> Create embedding tab.
2. Below the usual fields (Name / Initialization Text / Numbers of vectors per token / Overwrite old embedding?) and "Create Embedding" button. There is another field named "Embedding to copy", which lists all currently loaded embedding, and then a button that says "Copy Embedding"

OR

Change the behavior of the "Initialization Text" parameter. So setting it as the name of an old embedding copies its parameters to the new embedding.

### Additional information

_No response_
Repository: node
Issue: Crash if wrong hex string is written to http.ClientRequest
Labels: confirmed-bug,http

### Version

19.0.0 (but happens also on older versions, last retest with 21.4.0)

### Platform

all

### Subsystem

http, maybe streams

### What steps will reproduce the bug?

if an invalid hex encoded string is written to a `http.ClientRequest` node crashes/asserts.

```js
const http = require("http");

const request = http.request("http://example.org", {method: "POST"});
request.write("1", "hex");
```

### How often does it reproduce? Is there a required condition?

always

### What is the expected behavior?

More graceful error handling like a JS exception.

### What do you see instead?

assert/crash

```
node[360]: ../src/string_bytes.cc:420:static v8::Maybe<long unsigned int> node::StringBytes::StorageSize(v8::Isolate*, v8::Local<v8::Value>, node::encoding): Assertion `str->Length() % 2 == 0 && "invalid hex string length"' failed.
 1: 0xbbf330 node::Abort() [node]
 2: 0xbbf3ae  [node]
 3: 0xcaf8ba node::StringBytes::StorageSize(v8::Isolate*, v8::Local<v8::Value>, node::encoding) [node]
 4: 0xca562a node::StreamBase::Writev(v8::FunctionCallbackInfo<v8::Value> const&) [node]
 5: 0xca7876 void node::StreamBase::JSMethod<&node::StreamBase::Writev>(v8::FunctionCallbackInfo<v8::Value> const&) [node]
 6: 0xe03f00  [node]
 7: 0xe05356 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
 8: 0x17fb3f9  [node]
Aborted (core dumped)
```

### Additional information

This seems to be not limited to http, net shows same problem with following code:
```js
const net = require("node:net");
const s = net.createConnection(8000);
s.on("connect", () => {
    s.cork()
    s.write("a")
    s.write("1", "hex");
    s.uncork()
});
```
Interesting is that following net sample doesn't crash:
```js
const net = require("node:net");
const s = net.createConnection(8000);
s.on("connect", () => {
    s.write("1", "hex");
});
```
Seems in this case the single, invalid hex encoded byte is silently discarded.
Repository: vscode
Issue: Windows: Context menu doesn't work in ARM64
Labels: bug,workbench-os-integration,windows 11,system-context-menu

> I am going to merge this PR for insiders testing and follow-up on the arm64 issue.

_Originally posted by @deepak1556 in https://github.com/microsoft/vscode/issues/151186#issuecomment-1287124875_
Repository: pytorch
Issue: ninja: build stopped: subcommand failed
Labels: needs reproduction,module: build,triaged

### 🐛 Describe the bug

Getting the following output when running `setup.py install` which results in the build failing.
![image](https://user-images.githubusercontent.com/54014218/197547147-b5a20035-1115-4e91-938f-17c37d1410ef.png)


### Versions

![image](https://user-images.githubusercontent.com/54014218/197547296-0f55577b-fc7b-4a07-aa82-5fbe654a149a.png)


cc @malfet @seemethere
Repository: deno
Issue: Expose the import-map URL under `import.meta`
Labels: web,upstream

Related to #12575

### Summary
If a user specifies an import-map in their Deno config, Deno should/could expose the URL globally. In my opinion, it should go under `import.meta`. It seems that the ECMAScript committee purposely left `import.meta` extensible [^1].

#### Use cases
- Bundling code
- Transforming Deno code for browser-use
- Updating dependencies

### Notes
Assuming the property is read-only, it might be easier for everyone to expose the import-map's object itself. This would mean less parsing. But it should be read-only, to adhere to the specification.

I did see [the WICG's note](https://github.com/WICG/import-maps#programmatic-api) about a programmatic API. The discussions seem to center around browser-usage. The most relevant open issue (https://github.com/WICG/import-maps/issues/128) focuses on exposing the entire import-map as an object (not just the URL), and allowing modifications (not read-only).

[^1]: https://github.com/tc39/proposal-import-meta#will-this-object-be-locked-down-in-any-way
Repository: next.js
Issue: Jest tests are failing when dynamic imports are used
Labels: bug,Lazy Loading,Testing

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.0.1: Tue Sep 14 20:56:24 PDT 2021; root:xnu-8019.30.61~4/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.17.1
      npm: 8.15.0
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.3.2-canary.38
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0


### What browser are you using? (if relevant)

Not relevant

### How are you deploying your application? (if relevant)

Not relevant

### Describe the Bug

This is the same issue as https://github.com/vercel/next.js/issues/36647, which is locked and closed.
When using dynamic imports, jest tests are failing with an error:
```
Warning: An update to ForwardRef(LoadableComponent) inside a test was not wrapped in act(...)
```
But wrapping it in `act` is also not working. This seems to have been introduced in v12.1.6-canary.9, possibly related to these changes: https://github.com/vercel/next.js/pull/36464

### Expected Behavior

Dynamic imports should work out-of-the-box in all environments.

### Link to reproduction

https://github.com/buesing/next-dynamic-components-jest

### To Reproduce

Install dependencies, then run `npm run test`.
Repository: TypeScript
Issue: Quick fix on TS80006 got not equivalent codes
Labels: Bug,Help Wanted,Domain: Refactorings

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.72.2
- OS Version: Windows 10

Steps to Reproduce:

Consider these codes:
```javascript
function makeRequest() {
    try {
        const promise = fetchApi();
        // not async/await style, got indicates TS80006: This may be converted to an async function
        return promise.catch(error => {
            console.log('catch1');
            throw new Error('wrap error');
        });
    } catch (error) {
      console.warn('catch2: this line should never be reached');
      return Promise.resolve('wrong return');
    }
}

async function fetchApi() {
    throw new Error('network error')
}
```

By quick fix, we expect:
```javascript
function makeRequest() {
    try {
        const promise = fetchApi();
        return (async () => {
            try {
                return await promise;
            } catch (error) {
                console.log('catch1');
                throw new Error('wrap error');
            }
        })();
    } catch (error) {
      console.warn('catch2: this line should never be reached');
      return Promise.resolve('wrong return');
    }
}
```

But actually we got:
```javascript
async function makeRequest() {
    try {
        const promise = fetchApi();
        try {
            return await promise;
        } catch (error) {
            console.log('catch1');
            throw new Error('wrap error');
        }
    } catch (error) {
      console.warn('catch2: this line should never be reached');
      return Promise.resolve('wrong return');
    }
}
```

The second catch statement will be executed incorrectly.