sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: ollama
Issue: Loosing useragent after HTTP redirect while pulling models
Labels: bug

### What is the issue?

When pulling a model, a first HTTP GET call is issued using a specific ollama user agent (like `ollama/0.4.2`).  The following GET requests to cloudflare use a different user agent (`Go-http-client/1.1`).

My company use firewall rules based on domains and user agents. Ollama should use a consistent useragent for all its http requests

Logs from my IT department (pulling nomic-embed-text):
```
[22/Nov/2024:15:47:19 +0100] "" int.ern.ali.pv4 307 "GET https://registry.ollama.ai/v2/library/nomic-embed-text/blobs/sha256:970aa74c0a90ef7482477cf803618e776e173c007bf957f635f1015bfcfef0e6 HTTP/2.0" "Business, Software/Hardware" "Minimal Risk" "text/html" 1304 "ollama/0.4.2 (arm64 darwin) Go/go1.23.3" "" "0" ipv6:here:removed
[22/Nov/2024:15:47:50 +0100] "" int.ern.ali.pv4 206 "GET https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/97/970aa74c0a90ef7482477cf803618e776e173c007bf957f635f1015bfcfef0e6/data?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxx&X-Amz-Date=20241122T144719Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=xxx HTTP/1.1" "Content Server" "Minimal Risk" "application/octet-stream" 74291068 "Go-http-client/1.1" "" "0" ipv6:here:removed
[22/Nov/2024:15:47:51 +0100] "" int.ern.ali.pv4 206 "GET https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/97/970aa74c0a90ef7482477cf803618e776e173c007bf957f635f1015bfcfef0e6/data?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxx&X-Amz-Date=20241122T144719Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=xxx HTTP/1.1" "Content Server" "Minimal Risk" "application/octet-stream" 100000413 "Go-http-client/1.1" "" "0" ipv6:here:removed
[22/Nov/2024:15:47:55 +0100] "" int.ern.ali.pv4 206 "GET https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/97/970aa74c0a90ef7482477cf803618e776e173c007bf957f635f1015bfcfef0e6/data?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxx&X-Amz-Date=20241122T144719Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=xxx HTTP/1.1" "Content Server" "Minimal Risk" "application/octet-stream" 100000404 "Go-http-client/1.1" "" "0" ipv6:here:removed
```

### OS

macOS

### GPU

Apple

### CPU

Apple

### Ollama version

0.4.2
Repository: pytorch
Issue: Burn down test/functorch/test_aotdispatch.py OpInfo test failures
Labels: module: tests,triaged,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

As part of PT2 hardening / user empathy for AOTDispatcher:

(1) we have a big suite of tests that run all of our OpInfos through AOTDispatcher, and [roughly ~71 of them xfailed ](https://github.com/pytorch/pytorch/blob/main/test/functorch/test_aotdispatch.py#L6333)(or even worse, skipped). We should burn down these failures. Many of them appear to be e.g. missing symbolic meta functions. We hit one of these from the last user empathy day ([issue](https://github.com/pytorch/pytorch/issues/141187))

(2) If we think that this class of errors will stick around for a while, we should consider making the error message better. For example, given the crash in this [issue](https://github.com/pytorch/pytorch/issues/141187), there are quite a few things we could have improved about the error message:

**improvement ideas**

(a) The error didn't include the name of the op that we failed to trace (`_upsample_bilinear2d_aa_backward`)

(b) The error didn't mention anything about "missing fake tensor rule" - it gave a pretty opaque error about `RuntimeError: isIntList() INTERNAL ASSERT FAILED at "/pytorch/aten/src/ATen/core/ivalue_inl.h":1979`

(c) If we fix both of those, it should theoretically be possible to figure out that the "culprit" user code is coming from a call to `torch.nn.functional.interpolate(..., antialias=True)`, and recommend that they file an issue / work around with a "traceable" annotation

cc @mruberry @ZainRizvi @chauhang @penguinwu @zou3519 @yf225
Repository: pytorch
Issue: Support saving pytorch models in OCI registries
Labels: module: serialization,triaged,enhancement

### 🚀 The feature, motivation and pitch

This is an idea that come to my mind while I was thinking on how to help users to use ML model in the cloud. I'm aware that there are dedicated projects on build and distributing ML model in the cloud like Kubeflow. But I think it could not worth the effort to deploy this infrastructure when users have a small environment and just want to put a model to run somewhere and do some proof of concept. Therefore, I have the idea to use one of the most common component in a cloud environment to distribute models, the container registries. To be more precise an OCI registry.  This is not exactly a new idea. The [Kubewarden](https://www.kubewarden.io/) project already use OCI registry to distribute WASM modules. Thus, I think the same principle could be applied to distribute pytorch models.

I'm not considering this a best practice for a production environment considering all the meta data associated to a model. But it could be a starting point for something interesting in the future. 

> [!WARNING]  
> As I'm not familiarized with the AIOps, I don't know if this make sense to the project. But I think it worth to share and get some feedback


### Alternatives

Maybe projects dedicated to the machine learning models, like Kubeflow, could be changes to make usage of OCI registries removing this from pytorch. But this is out of scope of this project. 

### Additional context

- This is a random idea that came to my mind while I was learning more about OCI \
- This POC is a result of a SUSE Hack week spend on learning more about OCI and pytorch

cc @mruberry @mikaylagawarecki
Repository: rust
Issue: Tracking issue for release notes of #102575: const_collections_with_hasher, build_hasher_default_const_new
Labels: T-libs-api,relnotes,relnotes-tracking-issue


This issue tracks the release notes text for #123197 and https://github.com/rust-lang/rust/issues/102575.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Stabilized APIs
- [`BuildHasherDefault::new`](https://doc.rust-lang.org/stable/std/hash/struct.BuildHasherDefault.html#method.new)
# Const stabilized APIs
- [`HashMap::with_hasher`](https://doc.rust-lang.org/stable/std/collections/struct.HashMap.html#method.with_hasher)
- [`HashSet::with_hasher`](https://doc.rust-lang.org/stable/std/collections/struct.HashSet.html#method.with_hasher)
- [`BuildHasherDefault::new`](https://doc.rust-lang.org/stable/std/hash/struct.BuildHasherDefault.html#method.new)
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @krtab, @krtab -- origin issue/PR authors and assignees for starting to draft text
Repository: angular
Issue: in angular.dev add signal/non-signal toggle
Labels: area: docs

### Which @angular/* package(s) are relevant/related to the feature request?

_No response_

### Description

right now there are two ways to do things in Angular, and they are in some situations completely different approaches how to solve them - e.g. using computed vs using input setter - and while this isn't a temporary situation as Angular team promised to keep the support for zone.js for a long future
this will mean as an Angular developer I will have to deal with both signal based and non-signal based way of doing things, and from the ngPoland I understand that there will be even more changes coming to Forms, Routing and HttpClient to be built with signals in mind
that will make Angular projects in the future become completely different flavor of being signal/zoneless or zoned/non-signal
that leaves a big problem in the long term documentation, of course they will be updated to match the new signal flavor, but when developers want to go to to the docs to find how to do things in a non-signal project they will not find any

### Proposed solution

the angular.dev should have where it make sense a tab/toggle to show the content that is related to signal or non-signal
it should behave similar to https://typescript-eslint.io/users/configs/#projects-without-type-checking where you switch between flat config and legacy config but between signal/non-signal way, it could be even called signal/legacy to show people that they are using an old API and encourage them to update
I understand that will make the angular.dev more complicated but it's useful for developers who started their career and learning Angular with Signals with mind, then go to work on a company where they have still some code using the non-signal way

### Alternatives considered

two alternatives
1. that when people want to see the other way to do things to go to old docs https://v17.angular.io/docs
  this approach have a problem about changes that were made to these things, let's imagine in the future there is a new method added to the non-signal route service, now these old docs won't have it, that's especially useful for scenarios where Angular team might have added this method to make it easier to switch to the signal-based route
2. to have seperate pages for signal and non-signals things that are significantly different and different sections or a note for the other pages that have small yet important change between them
  this approach is less complicated from technical perspective, but less user friendly since users will be seeing pages/sections unrelated to what they are looking for
Repository: kubernetes
Issue: Flexvolumes should be mountable when non-attachable flaky tests
Labels: sig/storage,kind/flake,kind/failing-test,needs-triage

### Failure cluster [4176883069dfc8454c66](https://go.k8s.io/triage#4176883069dfc8454c66)

![image](https://github.com/user-attachments/assets/abe3b011-7f59-4d39-9078-15f287206a19)


##### Error text:
```
[FAILED] Failed to create client pod: Timed out after 300.000s.
Expected Pod to be in <v1.PodPhase>: "Running"
Got instead:
    <*v1.Pod | 0xc003627688>: 
        metadata:
          creationTimestamp: "2024-11-09T11:27:28Z"
          labels:
            role: flex-client
          managedFields:
          - apiVersion: v1
            fieldsType: FieldsV1
            fieldsV1:
              f:metadata:
                f:labels:
                  .: {}
                  f:role: {}
              f:spec:
                f:affinity:
                  .: {}
                  f:nodeAffinity:
                    .: {}
                    f:requiredDuringSchedulingIgnoredDuringExecution: {}
                f:containers:
                  k:{"name":"flex-client"}:
                    .: {}
                    f:command: {}
                    f:image: {}
                    f:imagePullPolicy: {}
                    f:name: {}
                    f:resources: {}
                    f:securityContext:
                      .: {}
                      f:privileged: {}
                    f:terminationMessagePath: {}
                    f:terminationMessagePolicy: {}
                    f:volumeMounts:
                      .: {}
                      k:{"mountPath":"/opt/0"}:
                        .: {}
                        f:mountPath: {}
                        f:name: {}
                    f:workingDir: {}
                f:dnsPolicy: {}
                f:enableServiceLinks: {}

```
#### Recent failures:
[11/22/2024, 1:38:37 PM pr:pull-kubernetes-e2e-gce-canary](https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/128889/pull-kubernetes-e2e-gce-canary/1859939306492137472)
[11/22/2024, 1:24:18 PM pr:pull-kubernetes-e2e-gce-canary](https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/125230/pull-kubernetes-e2e-gce-canary/1859935684870017024)
[11/22/2024, 1:07:39 PM pr:pull-kubernetes-e2e-gce-canary](https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/128650/pull-kubernetes-e2e-gce-canary/1859930965229441024)
[11/22/2024, 12:36:06 PM pr:pull-kubernetes-e2e-gce-canary](https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/125230/pull-kubernetes-e2e-gce-canary/1859923588459532288)
[11/22/2024, 10:35:44 AM pr:pull-kubernetes-e2e-gce-canary](https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/128889/pull-kubernetes-e2e-gce-canary/1859893268624445440)

https://prow.k8s.io/job-history/gs/kubernetes-ci-logs/pr-logs/directory/pull-kubernetes-e2e-gce-canary

/kind failing-test
/kind flake
/sig storage
Repository: tailwindcss
Issue: [v4] --radius-full is not available as a variable
Labels: v4

<!-- Please provide all of the information requested below. We're a small team and without all of this information it's not possible for us to help and your bug report will be closed. -->

**What version of Tailwind CSS are you using?**

4 beta.2

**What build tool (or framework if it abstracts the build tool) are you using?**

Tailwind Play

**What version of Node.js are you using?**

N/A

**What browser are you using?**

Firefox

**What operating system are you using?**

macOS

**Reproduction URL**

https://play.tailwindcss.com/bpvuR7VY5Z

**Describe your issue**

`--radius-full` does not appear to be available as a variable. As an obviously pointless example`rounded-(--radius-lg)` will result in an element with rounded corners, `rounded-(--radius-full)` will not.
Repository: rust
Issue: cargo doc should render crate examples and link to them on main documentation page
Labels: T-rustdoc,C-enhancement,A-rustdoc-ui,A-rustdoc-scrape-examples,T-rustdoc-frontend

(re-filing of https://github.com/rust-lang/rust/issues/34022)

Cargo allows crate developers to create examples to show off their crate's API (as shown in http://doc.crates.io/guide.html#project-layout). These examples are very useful to see how the individual items in a crate can be used together, in a way that the standard documentation doesn't capture very well.

When viewing a crate's documentation, it would be useful if examples were rendered as standard source files, and there were links to view them on the main library overview page.
Repository: godot
Issue: Subtractive Blending doesn't work on Compatibility Renderer
Labels: bug,topic:rendering,needs testing,topic:3d

### Tested versions

I've tested various versions of Godot 4 going all the way back to when the Compatibility Renderer was first added. None of them have correctly rendered subtractive blending. It should be reproducible in any version of Godot 4 with the Compatibility Renderer.

### System information

Godot v4.4.dev5 - Windows 10.0.19045 - Multi-window, 3 monitors - OpenGL 3 (Compatibility) - NVIDIA GeForce RTX 3070 (NVIDIA; 32.0.15.6094) - AMD Ryzen 7 5800X 8-Core Processor (16 threads)

### Issue description

Subtractive Blended Materials show a solid color, instead of blending with whatever is drawn behind. This isn't an issue for Additive or Multiplicative Blended Materials.

In editor, it shows one of your editor theme colors:

![Image](https://github.com/user-attachments/assets/358d4c23-69fe-4ba5-ad3d-27f4528d5de3)

In game, it seems to show a solid gray:

![Image](https://github.com/user-attachments/assets/153812ae-943a-4d79-ac30-5d06b9956d88)


### Steps to reproduce

1. Create a project, set to Compatibility Renderer
2. Open a 3D Scene
3. Add a Camera3D
4. Add a MeshInstance3D, with a PlaneMesh rotated towards the Camera
5. Add a StandardMaterial3D to the MeshInstance3D, Shading Mode set to Unshaded, Blend Mode set to Subtract

### Minimal reproduction project (MRP)

N/A
Repository: next.js
Issue: SASS import error when adding carbon-components to nextjs with turbopack
Labels: bug,Turbopack,linear: turbopack

### Link to the code that reproduces this issue

https://github.com/krab7191/turbopack-sass-carbon-issue

### To Reproduce

1. Create a new nextjs project and choose to use Turbopack
2. Adjust React & React DOM versions to 18.2.0 as required peer deps 
3. Follow instructions to add [carbon-components](https://carbondesignsystem.com/developing/react-tutorial/overview/) (step 1)


### Current vs. Expected behavior

When running `npm run dev` the following error appears: 

```
Error evaluating Node.js code
Error: Can't find stylesheet to import.
  ╷
1 │ @use '@carbon/react';
```

When changing the sass use statement to `@use '@carbon/react/index.scss';` the error changes to:

```
Error evaluating Node.js code
Error: Can't find stylesheet to import.
  ╷
8 │ @forward '@carbon/colors';
```

Removing the `--turbopack` option from the "dev" script and restarting makes everything render properly, aka the button appears on the page.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 21.7.3
  npm: 10.5.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.0.3 // Latest available version is detected (15.0.3).
  eslint-config-next: 15.0.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Turbopack

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

_No response_
Repository: vscode
Issue: Explorerer becomes empty when `package.json` is presented
Labels: bug,file-explorer


Type: <b>Bug</b>

When there is a file named `package.json`, the whole explorer just becomes empty:
![Image](https://github.com/user-attachments/assets/2f2e53e5-028f-4d36-8632-1466a7116669)
As shown in the terminal on the right side, the directory is not empty, but those files are not displayed.

If I run `mv package.json <some other name>`, the explorer return to normal.
![Image](https://github.com/user-attachments/assets/97921a64-747b-4482-97db-6d5432fcfebf)

Renaming it back to `package.json`, the files disappears again.
![Image](https://github.com/user-attachments/assets/a0217a64-d1e0-465b-ac52-3f0c69c575fe)


VS Code version: Code 1.95.3 (f1a4fb101478ce6ec82fe9627c43efbf9e98c813, 2024-11-13T14:50:04.152Z)
OS version: Windows_NT x64 10.0.22631
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 x 2304)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|23.78GB (6.72GB free)|
|Process Argv|--crash-reporter-id ad512ff0-65b0-4430-b33b-feecc2d05dc6|
|Screen Reader|no|
|VM|47%|
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805cf:30301675
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
jg8ic977:31013176
dvdeprecation:31068756
dwnewjupyter:31046869
newcmakeconfigv2:31071590
nativerepl1:31139838
pythonrstrctxt:31112756
nativeloc1:31185841
cf971741:31144450
iacca1:31171482
notype1cf:31157160
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530

```

</details>

<!-- generated by issue reporter -->
Repository: go
Issue: os: consider mapping Unix permissions bits to Windows ACLs
Labels: NeedsDecision

The `os.FileMode`/`io/fs.FileMode` type represents a file's "mode and permission bits".

Permission bits are a Unix concept. `FileMode` exposes these bits directly: "The nine least-significant bits are the standard Unix rwxrwxrwx permissions." (The `FileMode` documentation doesn't even bother to specify which bit is which, assuming that this is common knowledge.)

On Windows, the `os` package translates the permission bits to the `FILE_ATTRIBUTE_READONLY` attribute:
- When creating a file, the file is created with `FILE_ATTRIBUTE_READONLY` if the bit 0o200 (user-writable) is not set.
- When statting a file, the mode bits are set to 0o444 if `FILE_ATTRIBUTE_READONLY` is set, 0o666 otherwise.

The `os` package does not attempt to distinguish between the user/group/other bits. It is not possible to create a file readable only by the current user. `os.CreateTemp` is documented as creating files with mode 0o600; while technically accurate (the best kind of accurate!), this is somewhat misleading on Windows because the file will be world read/writable.

A similar issue with Python temporary files was assigned CVE-2024-4030. After some discussion, we're inclined to say that `os.CreateTemp`'s current behavior is not a vulnerability since the `os` package's lack of support for Windows permissions is well-known and `CreateTemp` does indeed behave according to its documentation in that light. But it's certainly unfortunate.

This issue is to consider the possibility of mapping Unix permission bits to Windows ACLs in the `os` package. There are well-known security identifiers (SIDs) that translate fairly closely to the Unix concepts of user/group/other: `SECURITY_CREATOR_OWNER_RID`, `SECURITY_CREATOR_GROUP_RID`, and `SECURITY_WORLD_RID`. The OS package could set an ACL on new files using these SIDs, and possibly translate simple ACLs to Unix permissions when returning a `FileMode`.

Making this change has the risk of breaking existing programs that depend on the current behavior. We'd definitely want a GODEBUG to revert to the old behavior.
Repository: TypeScript
Issue: Missing `Go to definition` links when accessing properties after `jsdoc` typecast
Labels: Suggestion,Help Wanted,Experience Enhancement

### 🔎 Search Terms

jsdoc typecast, typecast property access, jsdoc go to definition

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about jsdoc, typecast


### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.6.3&filetype=js#code/PQKhAIAEBcE8AcCmATRAzcBvT4B2BDAW0QC5wBnaAJwEtcBzcAXyfADEB7D8EYAKD4BjDrkrgOAIwBW4ALzhQEGAkRZOHVrwAUmJgEoA3H2DBwACQ4A3RFXAB3GtAAW4AAaDqAG1fjrt1+o+EoieHHbgyByI5LgA5NDgVIjC9Lg0AF6qzlkqEeh0jjQiQiJiklIAjHIKYFBwSGpcmsA6+gB0BMRGwqIJ5QBM1Yp1uZjqza16ANqxnYixALpGfEA

### 💻 Code

```ts
/** @typedef {{ name: string }} Foo */

const obj = /** @type {Foo} */({});
// Hover with `ctrl` over `Foo` below doesn't recognize the type definition
const obj1 = /** @type {Foo} */({}).name;
const obj2 = /** @type {Foo} */({})['name'];
```


### 🙁 Actual behavior

Hovering over `Foo` with `ctrl` pressed doesn't recognize the type definition

### 🙂 Expected behavior

Hovering over `Foo` with `ctrl` pressed recognizes the type definition

### Additional information about the issue

_No response_