sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Kubelet not able to reclaim memory from buffer/cache and complains memory pressure and evicting pods
Labels: kind/bug,area/cadvisor,sig/node,lifecycle/rotten,triage/needs-information,needs-triage

### What happened?

One a few nodes   Kubelet says reclaiming memory and it doesn’t look to be doing any reclaim from Linux cache/buffer memory which is causing Memory Pressure status from Kubelet. Then it tries to evict pods and starts showing some of those pods as ContainerStatusNot Known. 

This is the cluster running on cgroups v2 and containerd

### What did you expect to happen?

It is expected to reclaim buffer/cache memory and not evict pods or go into an error state of Memory pressure as there is lot of memory available in the Linux Cache/buffer.

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

Use FCOS 37, containerd and cgroups v2

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version


# paste output here
```
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.13", GitCommit:"592eca05be27f7d927d0b25cbb4241d75a9574bf", GitTreeState:"clean", BuildDate:"2022-10-12T10:57:16Z", GoVersion:"go1.17.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.11", GitCommit:"0f75679e3346160939924550fd3591462a4afec6", GitTreeState:"clean", BuildDate:"2023-02-22T13:32:00Z", GoVersion:"go1.19.6", Compiler:"gc", Platform:"linux/amd64"}
</details>


### Cloud provider

<details>
Bare metal
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="37.20230122.3.0 (CoreOS)"
ID=fedora
VERSION_ID=37
VERSION_CODENAME=""
PLATFORM_ID="platform:f37"
PRETTY_NAME="Fedora CoreOS 37.20230122.3.0"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:37"
HOME_URL="https://getfedora.org/coreos/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-coreos/"
SUPPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
BUG_REPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=37
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=37
SUPPORT_END=2023-11-14
VARIANT="CoreOS"
VARIANT_ID=coreos
OSTREE_VERSION='37.20230122.3.0'
$ uname -a
Linux HOSTNAME 6.1.6-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 14 16:55:06 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


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

<details>
containerd-1.6.14-2.fc37.x86_64
</details>


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

<details>

</details>
Repository: stable-diffusion-webui
Issue: [Feature Request]: "Save a copy of image before <...>" into separate sub-folder
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 ?

Add additional settings option for saving copy of image before face restoration, high-res fix, etc. into separate sub-folder. 
```e.g. "outputs/txt2img-images/[date]/before-highres-fix"```





### Proposed workflow

Option 1:
For full user control each applicable "Save a copy..." should have this option separately under ```Settings -> Saving images/grids``` and ability to set path name under ```Settings -> Saving to a directory```

Option 2:
If first option adds to much clutter to settings menu or not optimal for performance then add global option under
```Settings -> Saving images/grids -> Save a copy of image before doing post-processing into sub-folder```


### Additional information

_No response_
Repository: bitcoin
Issue: Use different datadirs for different signets
Labels: Feature,Tests,good first issue

### Please describe the feature you'd like to see added.

From https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1513814497:

> This brings up a related issue in that we can't have multiple signets in the same base datadir. All signets use the signet datadir, so any change of parameter may result in a bad chainstate for that signet node.
> 
> I think we should instead look at implementing a more robust multiple signet solution that allows for multiple configurable consensus rules in a clean and simple way since clearly that's desired. Ideally we would have a single parameter that contains all of the rules being configured rather than having multiple for each rule. We should also make datadirs specific to each set of rules, ideally in a deterministic way.
Repository: godot
Issue: Unable to compile export templates for web - invalid switch "msys64"
Labels: platform:web,topic:buildsystem,needs testing

### Godot version

4.0.2

### System information

Windows 10

### Issue description

When trying to compile web export templates for 4.0.2, the build fails. `libfreetype` fails to link with error message `Invalid switch - msys64`.

Python: 3.10.10
Scons: 4.4.0
Emscripten: 3.1.36

Full output here: https://pastebin.com/QRPLLTck

### Steps to reproduce

1. Attempt to compile web templates
2. If your system is like mine, it won't work

### Minimal reproduction project

N/A
Repository: PowerToys
Issue: FancyZones not restoring windows when I switch virtual desktops
Labels: Issue-Bug,Product-FancyZones,Priority-2,FancyZones-VirtualDesktop

### Microsoft PowerToys version

0.69.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

I am connecting to the machine running PowerToys via RemoteDesktop using a 4K monitor.  When I disconnect from this machine, all my windows are moved as if a smaller monitor were connected.  When I reconnect, FancyZones restores all the windows on the current virtual desktop, but when I switch to another desktop, the windows are not restored to their zones.
[PowerToysReport_2023-04-19-10-03-08.zip](https://github.com/microsoft/PowerToys/files/11275883/PowerToysReport_2023-04-19-10-03-08.zip)


### ✔️ Expected Behavior

I was expecting the windows to be restored to their zones when I switched to the 2nd virtual desktop.

### ❌ Actual Behavior

The windows were not restored to their zones.

### Other Software

_No response_
Repository: neovim
Issue: jobstart's on_exit is delayed on Windows when pty=1
Labels: bug,platform:windows,job-control,event-loop

### Problem

The `on_exit` callback takes about 4 seconds until executing on Windows. While waiting, pressing a motion key makes it execute immediately.

This delay is present on Windows, but not on other platforms. This delay is present when `pty` is set to `v:true`, but not when it's set to `v:false`.

### Steps to reproduce

```vim
nvim --clean
:edit example.vim
```
Add the following lines:
```vim
let command = ['rundll32.exe']  " effectively a no-op

function End(job, status, type)
  echom 'End: ' .. strftime('%c')
endfunction

let jobstart_options = {
      \   'pty': v:true,
      \   'on_exit': function('End')
      \ }
echom 'Start: ' .. strftime('%c')
let jobnr = jobstart(command, jobstart_options)
```

Save and source the file.
```vim
:write
:source %
```

The start time prints, followed by the end time in about four seconds.

```
Start: 4/19/2023 12:41:14 PM
End: 4/19/2023 12:41:18 PM
```

Pressing a movement key immediately after sourcing causes the `on_exit` callback function to execute sooner.

```vim
:source %
" Press l to move the cursor right
```

```
Start: 4/19/2023 12:43:07 PM
End: 4/19/2023 12:43:07 PM
```

### Expected behavior

I expected the `on_exit` callback to execute sooner (in the case where no cursor movement was triggered immediately after sourcing).

### Neovim version (nvim -v)

Neovim 0.9.0

### Vim (not Nvim) behaves the same?

No (9.0) when using term_start (pty option not available for Windows, but a pty is seemingly used)

### Operating system/version

Windows 11

### Terminal name/version

cmd.exe

### $TERM environment variable

(empty)

### Installation

 nvim-win64.zip
Repository: pytorch
Issue: Cross compile Pytorch for ARM in Bazel
Labels: module: build,triaged,enhancement,module: arm

### 🚀 The feature, motivation and pitch

My company has bazel as our build system, we have x86 and arm platforms in our environments. We have a cross compiling toolchain for ARM from x86. Because of this, we desire to have pytorch cross compile to ARM in bazel. 

We have a working prototype that we would like to upstream. 

We are filing this feature request to gauge community interest in bazel cross compile support for ARM in pytorch! 

Doc outlining a bit more: https://docs.google.com/document/d/1U4cUcfC_IYePL3LRfaqih21gB8I9L2Te_VUvaX9Yia4/edit#heading=h.y26v9c48rho1 

### Alternatives

_No response_

### Additional context

_No response_

cc @malfet @seemethere
Repository: go
Issue: runtime: make the proportion of CPU the GC uses based on actual available CPU time and not GOMAXPROCS
Labels: NeedsInvestigation,compiler/runtime

Currently the Go GC sets its parallelism as 25% of `GOMAXPROCS`. In doing so, it effectively assumes the Go runtime has access to `GOMAXPROCS*N` seconds of CPU time in `N` seconds of wall time, which is true in many circumstances, but not all.

For example, if a container is configured to have 100 ms of CPU time available for each 1 second window of wall time and `GOMAXPROCS=4` (because that's how much parallelism is available on the machine), then the Go runtime is effectively assuming it can use 1 second of CPU time very 1 second of wall time on GC alone.

In practice, this is not true, resulting in significant CPU throttling that can hurt latency-sensitive applications. To be more specific, throttling in general is not really a Go runtime issue. The issue is that the GC _on its own_ is using more CPU over a given window of time than the container is actually allowed.

Another example where this can go awry is with `GOMEMLIMIT`. If a container with a small CPU reservation runs up against the memory limit and the GC starts to execute frequently enough to then subsequently hit the 50% GC CPU limit, that 50% GC CPU limit is going to be based on `GOMAXPROCS`. Once again, this results in significant throttling that can make an already bad latency situation worse.

One possible fix for this is to make the Go GC container-aware. Rather than set the GC CPU limit, or the 25% parallelism from `GOMAXPROCS`, the Go GC could derive these numbers from the container.

On Linux, that means using the CPU cgroups parameters `cpu.cfs_period_us` and `cpu.cfs_quota_us`. More specifically, the GC CPU limit is set to 50% of `cpu.cfs_quota_us` in any given window of `cpu.cfs_period_us`, while the GC's default mark-phase parallelism is 25% of `cpu.cfs_quota_us / cpu.cfs_period_us`. (Disclaimer: this second part I'm less sure about.)

The Go runtime would re-read these parameters regularly, for example every few seconds, to stay up-to-date with its current environment.
Repository: go
Issue: x/net/nettest: `TestableAddress` is not consistent with `TestableNetwork`
Labels: NeedsInvestigation

### What did you do?

Run the following program (https://go.dev/play/p/rwXVU67MVUC?v=gotip):
```go
package main

import (
	"golang.org/x/net/nettest"
)

func main() {
	println(nettest.TestableNetwork("ip6"))
	println(nettest.TestableAddress("ip6", "::1"))
}
```

### What did you expect to see?
Consistent answers: `TestableAddress` for an address on a given network should only be true if `TestableNetwork` is also true for that network.

### What did you see instead?

```
false
true
```

Specifically, today `TestableAddress` always returns `true` for networks that are not one of `unix`, `unixgram`, or `unixpacket`.

(attn @neild @ianlancetaylor)
Repository: go
Issue: x/build/cmd/relui: improve security release automation
Labels: Builders,NeedsFix

Doing a security release involves quite a bit of manual work from the release coordinator. For an initial cut, let's see if we can automate assembling the internal commits into a branch, and exporting the changes from that branch on release day.
Repository: flutter
Issue: [flutter_tools] The `UserMessages` class should be deprecated
Labels: tool,P3,c: tech-debt,team-tool,triaged-tool

The tool has a [`UserMessages` class](https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/base/user_messages.dart) that houses some user messages displayed to the user by the flutter tool. However, _many_ messages are not stored in this class ([example](https://github.com/flutter/flutter/blob/68ec71f46c0a1210593cbcb34b1a7001d07a43c4/packages/flutter_tools/lib/src/android/android_studio.dart#L503-L504)).

Going back to the PR that introduced it, it's still unclear what the original intent was. See [this comment from @Hixie on the PR](https://github.com/flutter/flutter/pull/23889#issuecomment-448807150).

The class does allow partial reimplementations of the flutter tool to override messages, and it sees very light use in g3. However, it is unclear if this is worth the confusion this class can cause.

Some possible ways to address this:
* Delete the class entirely, either removing the g3 message overrides entirely or finding some other way to enable g3 specific messages.
* Rename and document the class to better describe it's specific purpose. Perhaps the class should only contain messages that need to be overridden in g3.
* Be consistent and have _all_ user messages stored in this class. This would probably result in more trouble than it's worth.
Repository: godot
Issue: Box Containers treat children size as Int when sorting instead of Float
Labels: discussion,topic:gui

### Godot version

3.5.stable

### System information

Windows 10 (doesn't really matter)

### Issue description

This is a straight forward issue but quite an odd one,
As you can see [here](https://github.com/godotengine/godot/blob/3.5/scene/gui/box_container.cpp#L64) box containers use `Size2i` to calculate its children size for sorting, even though the size is a Vector2 float, the conversion causes a loss of data that can be problematic. I'm surprised this hasn't been reported before (as far as my searching goes) but I ran into this in a project of mine that requires a `HboxContainer` to sort children of type `ColorRect` in a way that fills the entire screen.
I've recreated the issue in a separate project (see reproduction project), if this is a bug then I can make an attempt to fix it but if it's intended then it's quite problematic and I cannot think of a workaround other than brute-forcing the size of the sorted objects until if looks right.

Please note that the link I've provided could be wrong and that may not be the actual reason behind this issue, but the one thing I'm certain of after hours of debugging is that the issue is caused because the container treats its children size as a Vector2 of integers.

### Steps to reproduce

see minimal project

### Minimal reproduction project

[box_container_bug.zip](https://github.com/godotengine/godot/files/11276283/box_container_bug.zip)
Repository: PowerToys
Issue: There is no question mark option in the drop down menu for remaping keys 
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Needs-Triage

### Microsoft PowerToys version

v0.69.1

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

There is no question mark option in the drop down menus for remaping keys or shortucts.

### ✔️ Expected Behavior

That the question mark option would be available

### ❌ Actual Behavior

The question mark option is not in the list. Neither is the VK code.

### Other Software

_No response_
Repository: godot
Issue: PointLight2D doesn't respect Nearest texture filter for normal-maps or shadows
Labels: topic:rendering,good first issue,documentation,topic:2d

**TLDR** - jump to this post: https://github.com/godotengine/godot/issues/76266#issuecomment-1751739538

---

### Godot version

4.0.2.stable.official

### System information

Linux & Windows, various hardware

### Issue description

We can see the **expected behavior** for PointLight2D - each pixel of the Sprite2D is shaded without any interpolation or filtering, when we zoom in.
![light_not_scaled_no_normal_map](https://user-images.githubusercontent.com/6893111/233185864-ed0b2728-0241-4bba-983f-e0e8dab7b3bf.png)

When the light texture is scaled down, we can see that the shading actually happens for each pixel of the scaled light texture, even if pixels of the Sprite2D are bigger. I assume this is also **expected behavior**.
![light_scaled_down_4x_no_normal_map](https://user-images.githubusercontent.com/6893111/233187033-a3f4ec28-5aab-4bcd-9c28-02135c4e1ab7.png)


But when we use the CanvasTexture with NormalMap, suddenly the lighting is being interpolated for each screen pixel (the light pixels suppose to be the same size as sprite's). Setting the texture filter to Nearest does not fix this.
![light_not_scaled_with_normal_map](https://user-images.githubusercontent.com/6893111/233188931-5e981618-92ef-4f01-8ecc-a669e27428b2.png)

It seems that the `light()` shader is being run for each screen pixel (despite Camera2D zooming), which besides some performance impact, would be acceptable on its own. But this also causes the CanvasTextures to look ugly for pixel-art games with in-game zooming (and it looks even worse for some custom shaders).

### Steps to reproduce

1. Add Sprite2D and set it's texture to CanvasTexture
2. Load some Diffuse and NormalMap textures
3. Add Camera2D and zoom it in to see individual pixels clearly
4. Add PointLight2D with some texture
5. Set texture filter to Nearest for all components (and observe there is no difference)

### Minimal reproduction project

[light_pixel_test.zip](https://github.com/godotengine/godot/files/11277026/light_pixel_test.zip)
Repository: rust
Issue: out of memory compiling trait cycle
Labels: I-crash,T-compiler,I-compilemem,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
// Test that we properly detect the cycle amongst the traits
// here and report an error.

use std::panic::RefUnwindSafe;

trait Database {
    type Storage;
}
trait HasQueryGroup {}
trait Query<DB> {
    type Data;
}
trait SourceDatabase {
    fn parse(&self) {
        loop {}
    }
}

struct SalsaStorage {
    _parse: <ParseQuery as Query<RootDatabase>>::Data,
    //~^ ERROR overflow
}
struct RootDatabase {
    _runtime: Runtime<RootDatabase>,
}
struct Runtime<DB: Database> {
    _storage: Box<DB::Storage>,
}
struct SalsaStorage {
    _parse: <ParseQuery as Query<RootDatabase>>::Data,
    //~^ ERROR overflow
}

impl Database for RootDatabase {
    // This would also be an error if we didn't abort compilation on the error
    // above.
    type Storage = SalsaStorage;
}
impl HasQueryGroup for RootDatabase {}
impl<DB> Query<DB> for ParseQuery
where
    DB: SourceDatabase,
    DB: Database,
{
    type Data = RootDatabase;
}
impl<T> Database for T
where
    T: RefUnwindSafe,
    T: HasQueryGroup,
{
}

pub(crate) fn goto_implementation(db: &RootDatabase) -> u32 {
    // This is not satisfied:
    //
    // - `RootDatabase: SourceDatabase`
    //   - requires `RootDatabase: RefUnwindSafe` + `RootDatabase: HasQueryGroup`
    // - `RootDatabase: RefUnwindSafe`
    //   - requires `Runtime<RootDatabase>: RefUnwindSafe`
    // - `Runtime<RootDatabase>: RefUnwindSafe`
    //   - requires `DB::Storage: RefUnwindSafe` (`SalsaStorage: RefUnwindSafe`)
    // - `SalsaStorage: RefUnwindSafe`
    //    - requires `<ParseQuery as Query<RootDatabase>>::Data: RefUnwindSafe`,
    //      which means `ParseQuery: Query<RootDatabase>`
    // - `ParseQuery: Query<RootDatabase>`
    //    - requires `RootDatabase: SourceDatabase`,
    // - `RootDatabase: SourceDatabase` is already on the stack, so we have a
    //   cycle with non-coinductive participants
    //
    // we used to fail to report an error here because we got the
    // caching wrong.
    SourceDatabase::parse(db);
    22
}

fn main() {}

```

I used `prlimt` to limit memory consumption to ~3gb: `prlimit --noheadings --as=2000000000 rustc file.rs`

in icemaker I would get `thread 'rustc' panicked at 'allocating stack failed with: Cannot allocate memory (os error 12)', /cargo/registry/src/index.crates.io-6f17d22bba15001f/stacker-0.1.15/src/lib.rs:168:21` but I have not been able to reproduce this outside of it yet
Repository: next.js
Issue: Fast Reload doesn't work when non-React files are changed
Labels: bug

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #22 SMP Tue Jan 10 18:39:00 UTC 2023
    Binaries:
      Node: 18.14.2
      npm: 9.5.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.3.0
      eslint-config-next: 13.2.4
      react: 18.2.0
      react-dom: 18.2.0
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/serene-shamir-y960dv?file=%2Fgame%2Findex.ts&selection=%5B%7B%22endColumn%22%3A22%2C%22endLineNumber%22%3A3%2C%22startColumn%22%3A22%2C%22startLineNumber%22%3A3%7D%5D

### To Reproduce

Steps to reproduce:
1 - Open a new browser tab
2 - Open a dev console
3 - Go to the reproduction link and run the server on port `3000` using `yarn dev`;
4 - Check that you see the next intro page and that the Game logs `"Game!"` to the console;
5 - Try changing `game/index.ts` file (e.g., `"Game!"` to `"Game1!"`;
6 - Notice that when you change it, there's no fast reload happening. The game should have logged "Dispose!" to the console.


### Describe the Bug

I use a simple React component that uses a class called Game like this:
```typescript
import { Game } from "@/game"

const App = () => {
  useEffect(() => {
    const game = new Game()
    
    return () => {
        game.dispose()
    }
  })
  
  //...
}
```

Problem: whenever I change the Game file I'd expect the App to unmount and mount, but it doesn't happen.
In Next docs (https://nextjs.org/docs/basic-features/fast-refresh#how-it-works) it says that:
> If you edit a file with exports that aren't React components, Fast Refresh will re-run both that file, and the other files importing it. So if both Button.js and Modal.js import theme.js, editing theme.js will update both components.

Which contradicts what actually happens.

### Expected Behavior

The App component should completely re-render as it says in the NextJS docs.

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

Chrome

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

dev environment related