sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: cmd/go: add go mod verify -tag
Labels: Proposal,GoCommand

### Proposal Details

Go lacks a CLI to verify local repositories against the Go checksum database. Adding a **flag** in go mod verify to check local git tags against the sumdb would help module authors ensure their contents haven't been tampered with. This could prevent issues from unauthorized changes by someone with force-push access to GitHub, GitHub itself, or even Google.

I propose adding **a -tag flag accepting the following values**

all: Check all local git tags against the sumdb.
latest: Check only the latest local git tag
[version]: Check a specific version (e.g., go mod verify -tag=v1.0.0).

**-tag=latest is especially useful as the first command to run after pushing a new tag, as it will have the side-effect of loading it in the sumdb while checking it matches the local repository.**
Repository: puppeteer
Issue: [Bug]: Puppeteer v22.14.0 requires --no-sandbox when running on Windows as SYSTEM
Labels: bug,upstream,confirmed,P3

### Minimal, reproducible example

```TypeScript
import puppeteer from 'puppeteer';

const browser = await puppeteer.launch(
// Works when adding the following args:
//    { args: ['--no-sandbox'] }
);
const page = await browser.newPage();

await page.goto('https://pptr.dev/');
await page.screenshot({ path: 'pptr.png' });

await browser.close();
```


### Background

After trying to upgrade a longstanding project from Puppeteer v22.13.1 to v22.14.0, Puppeteer now fails to navigate to a page when running on Windows under the build-in SYSTEM account. This was observed in GitLab CI, where the [typical Windows configuration for the GitLab Runner service](https://docs.gitlab.com/runner/install/windows.html#installation) is running under the SYSTEM account. While there was no error message indicating a sandbox-related issue, and this occurs with `page.goto()`, the only resolution identified so far is to launch Puppeteer with the `--no-sandbox` arg.

This has previously not been required in this Windows configuration (this has been run in GitLab CI for years). When logging in to the same Windows GitLab runners, the test with Puppeteer v22.14.0 runs nominally as the logged in user. It also runs nominally on Linux. But, it consistently fails in this Windows configuration with v22.14.0, but continues to run nominally when reverting to v22.13.1. All of this behavior is consistent on both Windows 11 and Windows Server 2022, and when opening local HTML files or remote URLs.

It's unclear if this is expected or not, but checking the Chrome 127 release notes and full changelog there was not an obvious change indicating this behavior.

### Expectation

The script above should run without `--no-sandbox`, as previous versions of Puppeteer did.

### Reality

Puppeteer, running in Windows as SYSTEM, fails to navigate to a page. This behavior can be seen in the example GitLab CI job logs below:

- Windows 11, Node 20.16.0, without `--no-sandbox`, [fails with `net::ERR_ABORTED`](https://gitlab.com/gitlab-ci-utils/pagean/-/jobs/7468114247)
- Windows 11, Node 20.16.0, with `--no-sandbox`, [executes nominally](https://gitlab.com/gitlab-ci-utils/pagean/-/jobs/7468116287)
- Windows 2022, Node 21.2.0, without `--no-sandbox`, [fails with `net::ERR_ABORTED`](https://gitlab.com/gitlab-ci-utils/pagean/-/jobs/7463255407)
- Windows 2022, Node 21.2.0, with `--no-sandbox`, [executes nominally](https://gitlab.com/gitlab-ci-utils/pagean/-/jobs/7463223287)

The minimal example above fails with `net::ERR_ABORTED`, although the original project has also timed out with `Navigation timeout of 60000 ms exceeded` when running Puppeteer directly, or with the test framework (vitest) timing out on a test.


### Puppeteer configuration file (if used)

```TypeScript
Not used.
```


### Puppeteer version

22.14.0

### Node version

20.16.0

### Package manager

npm

### Package manager version

10.8.1

### Operating system

Windows
Repository: kubernetes
Issue: Kubernetes Pod Creation Fails Due to Misdirected Image Verification for Locally Tagged 
Labels: kind/support,sig/node,lifecycle/rotten,needs-triage

### What happened?

When using containerd to re-tag  private registry images without specifying the full domain, Kubernetes pods fail to start due to an incorrect attempt to verify the existence of the image on docker.io, even when the image is sourced from a private registry and is locally available.
This issue does not occur if the docker.io/library prefix is explicitly used during the tagging process.

### What did you expect to happen?

Pod creation should succeed using the locally available image from the private registry, regardless of how the image was tagged within containerd. 

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

Tag an image from a private registry without specifying the full domain:
```
ctr -n k8s.io i tag <private_registry>/<namespace>/<image>:<tag> <image>:<tag>
```
Create a pod referencing the local image (<private_registry>/<namespace>/<image>:<tag>). The pod creation will fail with an error indicating that the image docker.io/library/<image>:<tag> cannot be found.

### Anything else we need to know?

To avoid and fix this issue, explicitly specify the docker.io/library prefix when tagging images with containerd.
Both AliCloud and Amazon Cloud replicate the bug.

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
```
AliCloud: Server Version: v1.26.3-aliyun.1

Amazon Cloud: Server Version: v1.28.9-eks-036c24b
</details>


### Cloud provider

<details>
AliCloud and Amazon Cloud
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# 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>
AliCloud: containerd github.com/containerd/containerd v1.6.28 621ff9080dc3e797f4433a3bcf6439ff50ad898c
Amazon Cloud: containerd github.com/containerd/containerd 1.7.11 64b8a811b07ba6288238eefc14d898ee0b5b99ba
</details>


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

<details>

</details>
Repository: godot
Issue: Editor command line --doctool option stalls on generating new docs
Labels: bug,topic:editor,needs testing

### Tested versions

- Reproducible in: 4.2.2.stable [15073afe3], 4.3.rc [3e0c10d39]

### System information

Godot v4.3.rc (3e0c10d39) - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 with Max-Q Design (NVIDIA; 30.0.15.1278) - AMD Ryzen 9 4900HS with Radeon Graphics (16 Threads)

### Issue description

When running the editor with the `--doctool` option from the command line, the program loads the docs and erases the old docs, but it stalls for >1 hour on "Generating new docs...". I assume this is a long-running operation, but the wait time seems excessively long, and there is no indication of progress.

I was looking into updating some class reference documentation by following [this guide](https://docs.godotengine.org/en/latest/contributing/documentation/updating_the_class_reference.html), but it didn't mention how long the doctool is expected to run or if there were any required build options for the doctool to work.

### Steps to reproduce

0. Clone the Godot repository
1. Build with `scons .`
2. Run `.\bin\godot.windows.editor.x86_64.exe --doctool`
3. Wait...

### Minimal reproduction project (MRP)

N/A
Repository: rust
Issue: Recursive ..Default::default() overflows
Labels: A-lints,T-compiler,C-discussion

<!--
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
#[derive(Debug)]
struct Foo {
    bar: u32
}

impl Default for Foo {
    fn default()-> Self {
        Self {
            ..Default::default()
        }
    }
}
fn main() {
    println!("{:?}",Foo::default());
}
```

**I expected to see this happen:** Default values for each field


**Instead, this happened:** Infinite recursion and stack overflow

### Discussion

I know that what I was trying to do is not a supported syntax, but the overflow can be hard to debug and the warning is not super clear.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"mj10021"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: Switching between tabs in the editor causes flickering between tab contents
Labels: bug,topic:rendering,topic:editor

### Tested versions

- Reproducible in 4.3.rc1, 4.2.2.stable and 4.1.4.stable. Have not tested any earlier versions yet.

### System information

Godot v4.3.rc1 - Arch Linux #1 ZEN SMP PREEMPT_DYNAMIC Fri, 28 Jun 2024 04:32:27 +0000 - Wayland - Vulkan (Forward+) - dedicated NVIDIA GeForce GT 730M (nvidia; 470.256.02) - Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz (4 Threads)

### Issue description

When I switch between tabs, like the Scene and Import tabs, or the different scenes in the editor, then the view for the content that the tab represents starts flickering back and forth between the previous tab and new one. It also sometimes causes other elements of the UI to flicker as well. When I move my cursor off of the tabs then the flickering subsides.

https://github.com/user-attachments/assets/d1912217-abc1-49ac-a71b-2f477d251d76

https://github.com/user-attachments/assets/a569fcb2-60ca-4392-aa9a-9eee49c7616f

### Steps to reproduce

The bug is visible in new projects.

### Minimal reproduction project (MRP)

N/A
Repository: node
Issue: Inconsistent behavior handling malformed HTTP requests in HTTP Module
Labels: http

### Version

20.12.2

### Platform

```text
Windows 64-bit
```


### Subsystem

http

### What steps will reproduce the bug?

Create a server using the `http` module. Send a malformed HTTP request to the server. Observe the server's response and behavior.

### How often does it reproduce? Is there a required condition?

The issue reproduces consistently with malformed HTTP requests.

### What is the expected behavior? Why is that the expected behavior?

The server should handle malformed requests gracefully without crashing. This is necessary to avoid security crashes. 


### What do you see instead?

The server exhibits inconsistent behavior and may crash, depending on the nature of the request.

### Additional information

This issue was identified during unit testing using the Mocha testing framework and Chai assertion library.
Repository: ollama
Issue: Ollama运行Huggingface中下载的sqlcoder-34b-alpha模型报错:error loading model: vocab size mismatch
Labels: bug

### What is the issue?

执行命令：ollama run sqlcoder-34b-Q4_K_M
报错信息：
llama_model_load: error loading model: vocab size mismatch
llama_load_model_from_file: exception loading model
terminate called after throwing an instance of 'std::runtime_error'
  what():  vocab size mismatch
 
前置信息：通过llamap.cpp 执行了命令：
1.  python ./convert_hf_to_gguf.py  /home/user/datadisk-largemodel/sqlcoder-34b-alpha/  --outfile /home/user/datadisk-largemodel/sqlcoder-34b-alpha/sqlcoder-34b.gguf
2.  ./llama-quantize /home/user/datadisk-largemodel/sqlcoder-34b-alpha/sqlcoder-34b.gguf  /home/user/datadisk-largemodel/sqlcoder-34b-alpha/sqlcoder-34b-Q4_K_M.gguf  Q4_K_M

### OS

Linux

### GPU

Nvidia

### CPU

_No response_

### Ollama version

0.3.0
Repository: electron
Issue: [Bug]: Window with `minimizable: false` still shows activatable "Minimize" menu item
Labels: platform/macOS,bug :beetle:,status/confirmed,30-x-y,31-x-y,32-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

30.2.0

### What operating system(s) are you using?

macOS

### Operating System Version

MacOS 13.5.1

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

<img width="231" alt="image" src="https://github.com/user-attachments/assets/f6d03b78-df50-412e-951a-834c901e966e">

Minimize menu item is disabled


### Actual Behavior

<img width="546" alt="image" src="https://github.com/user-attachments/assets/896f8d96-d817-44cc-bb18-d7a6017a4842">

Minimize menu item is interactable, but does not cause any change in the window

### Testcase Gist URL

https://gist.github.com/Cloudkkk/34443bc82dcfd92b570a21cacf183df8

### Additional Information

_No response_
Repository: kubernetes
Issue: Couldn't collect kubelet_volume_* metrics of broken volume using cephfs.
Labels: kind/bug,sig/storage,lifecycle/rotten,needs-triage

### What happened?

Broken cephfs volume exists, but kubelet_volume_* metrics of it is not output.

As kubelet_volume_stats_health_status_abnormal metrics is not output, I can't detect volume health.

### What did you expect to happen?

The kubelet_volume_stats_health_status_abnormal should be output for broken volumes.
```
kubelet_volume_stats_health_status_abnormal{namespace="default",persistentvolumeclaim="broken"} 1
```

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

1. Enable feature gate for CSIVolumeHealth
2. Prepare PVCs which provisioned by cephfs and are Unhealthy.
3. Retrieve kubelet metrics and verify that there are no metrics for broken PVCs

### Anything else we need to know?

In ceph-csi, when an unhelthy volume is met, only the volumeCondition is returned as NodeGetVolumeStatsResponse.

In kubernetes, only those with Usage in NodeGetVolumeStatsResponse are accepted.

I think that it should accept only VolumeCondition without Usage.

https://github.com/ceph/ceph-csi/blob/e6540989a52212cf9b66672b4aa8fde19d037be6/internal/cephfs/nodeserver.go#L787

https://github.com/kubernetes/kubernetes/blob/2a1d4172e22abb6759b3d2ad21bb09a04eef596d/pkg/volume/csi/csi_client.go#L611-L638

### Kubernetes version

<details>

```console
$ kubectl version
Client Version: v1.30.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.10
WARNING: version difference between client (1.30) and server (1.28) exceeds the supported minor version skew of +/-1
```

</details>


### Cloud provider

<details>
baremetal
</details>


### OS version

<details>

```console
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
$ uname -a
Linux bm-008 5.15.0-112-generic #122-Ubuntu SMP Thu May 23 07:48:21 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
```

</details>


### Install tools

<details>

</details>


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

<details>

</details>


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

<details>
- rook-ceph-cluster: chart 1.14.5
- rook-ceph: chart 1.14.5
</details>
Repository: angular
Issue: Support angularCompilerOptions schema in tsconfig.json
Labels: area: compiler

### Command

config

### Description

Can the team support angularCompilerOptions type in `tsconfig.json` with schema, just like `$schema` defined in `angular.json`:

```json
{
    "$schema": "./node_modules/@angular/cli/lib/config/schema.json"
}
```

so user can change angularCompilerOptions with autocomplete feature and no typo there

### Describe the solution you'd like

_No response_

### Describe alternatives you've considered

_No response_
Repository: node
Issue: the require-cache-Behavior of  windows WHEN using lower-case-diskname  :   duplicated module(from same file)  IN require.cache
Labels: windows,loaders

### Version

v22.1.0.

### Platform

```text
PS D:\> echo "$([Environment]::OSVersion.VersionString) $(('x86', 'x64')[[Environment]::Is64BitOperatingSystem])"
Microsoft Windows NT 10.0.22631.0 x64
```


### Subsystem

_No response_

### What steps will reproduce the bug?


suppose we have a simple script fake-module.js under  C:\Users\dli>:
`
console.log("fake-module loaded:",{
    __filename: __filename,
    __dirname: __dirname
});
`

`
Microsoft Windows [版本 10.0.22631.3880]

C:\Users\dli>dir | findstr fake
2024/07/31  12:37                95 fake-module.js
C:\Users\dli>

### ----------------【noctice the disk name is UPPER-case C:】---------
C:\Users\dli>node
Welcome to Node.js v22.1.0.
Type ".help" for more information.
>

/*  
var mod0 = require("./fake-module");
var mod1 = require("C:\\Users\\dli\\fake-module.js");
var mod2 = require("c:\\Users\\dli\\fake-module.js");
*/



> var mod0 = require("./fake-module");
fake-module loaded: {
  __filename: 'C:\\Users\\dli\\fake-module.js',
  __dirname: 'C:\\Users\\dli'
}

> var mod1 = require("C:\\Users\\dli\\fake-module.js");
undefined
> var mod2 = require("c:\\Users\\dli\\fake-module.js");
fake-module loaded: {
  __filename: 'c:\\Users\\dli\\fake-module.js',
  __dirname: 'c:\\Users\\dli'
}
> mod0 === mod1
true 
> mod0 === mod2
false
>
> Object.keys(require.cache)
[ 'C:\\Users\\dli\\fake-module.js', 'c:\\Users\\dli\\fake-module.js' ]
>



###


### -----------【noctice the disk name is LOWER-case c:】---------

BUT if  some scripts USE cd "c:\Users\dli", such as:

cd "c:\Users\dli"
c:\Users\dli>

Welcome to Node.js v22.1.0.
Type ".help" for more information.


/*  
var mod0 = require("./fake-module");
var mod1 = require("C:\\Users\\dli\\fake-module.js");
var mod2 = require("c:\\Users\\dli\\fake-module.js");
*/

> var mod0 = require("./fake-module");
fake-module loaded: {
  __filename: 'c:\\Users\\dli\\fake-module.js',
  __dirname: 'c:\\Users\\dli'
}

> var mod1 = require("C:\\Users\\dli\\fake-module.js");
fake-module loaded: {
  __filename: 'C:\\Users\\dli\\fake-module.js',
  __dirname: 'C:\\Users\\dli'
}

> var mod2 = require("c:\\Users\\dli\\fake-module.js");
undefined
> mod0 === mod1
false
> mod0 === mod2
true
>
> Object.keys(require.cache)
[ 'c:\\Users\\dli\\fake-module.js', 'C:\\Users\\dli\\fake-module.js' ]
>
`

### How often does it reproduce? Is there a required condition?

always

### What is the expected behavior? Why is that the expected behavior?

I think  when require IF os.platform() is windows:   for disk-name, it should  case-insensitive. 

### What do you see instead?

duplicate modules

### Additional information

_No response_
Repository: PowerToys
Issue: Color picker open and close
Labels: Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

The color picker is basically the only tool that I use on a fairly regular basis from power toys. I find myself wanting to open it faster - either an icon on the taskbar, or an icon in the task tray. The current experience is to click an icon in the task tray and then choose color picker. One step too many. If an option can be added on how it should be opened, like adding an icon directly to the system tray, that would be great.

Frustratingly, every time I pick a color and then hit the delete button or the escape button, the tool closes automatically. I'd like to ability to make it disappear with a key of my choice, or just by clicking the x in the top right corner. It would be great if this was added as a choice as well.



### Scenario when this would be used?

The color picker is extremely handy, I use it quite a bit in testing items for accessibility color contrasts, and creating lists of colors.

### Supporting information

_No response_
Repository: node
Issue: Flaky `test-stream-readable-unpipe-resume`
Labels: flaky-test,linux

### Test

`test-stream-readable-unpipe-resume`

### Platform

Linux x64

### Console output

```console
14:09:40 not ok 3695 parallel/test-stream-readable-unpipe-resume
14:09:40   ---
14:09:40   duration_ms: 120099.24600
14:09:40   severity: fail
14:09:40   exitcode: -15
14:09:40   stack: |-
14:09:40     timeout
14:09:40   ...
```


### Build links

- https://ci.nodejs.org/job/node-test-commit-linux-containered/44931/nodes=ubuntu2204_sharedlibs_openssl31_x64/console

### Additional information

_No response_
Repository: stable-diffusion-webui
Issue: [Bug]: Windows 11 error - ERROR: python3 is not installed, aborting...
Labels: bug-report

### Checklist

- [ ] The issue exists after disabling all extensions
- [ ] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [ ] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

1. i enter the conda env, my python version is 3.9. 
2. when i run the webui.sh script, the error occured. from the Console logs, we can see an error info: 
ERROR: python3 is not installed, aborting...

### Steps to reproduce the problem

i just create a conda env, then, enter the env, and run pip install -r requirements.txt. it has no error. Finally, i run sh webui.sh in my git bash cmd. the error occured...


### What should have happened?

it should be fine, because the python env is ok.

### What browsers do you use to access the UI ?

Google Chrome

### Sysinfo

unnecessary

### Console logs

```Shell
(sd)
devin@Devin MINGW64 /d/Diffusion_Code/stable-diffusion-webui-master
$ python
Python 3.9.19 (main, May  6 2024, 20:12:36) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
(sd)
devin@Devin MINGW64 /d/Diffusion_Code/stable-diffusion-webui-master
$ sh webui.sh

################################################################
Install script for stable-diffusion + Web UI
Tested on Debian 11 (Bullseye), Fedora 34+ and openSUSE Leap 15.4 or newer.
################################################################

################################################################
Running on devin user
################################################################

################################################################
ERROR: python3 is not installed, aborting...
################################################################
```


### Additional information

Windows11 x64，GTX4090