sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: PV controller races with itself when you prebind a PVC
Labels: kind/bug,sig/storage,lifecycle/frozen

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->


**What happened**:
Offshoot of https://github.com/kubernetes/kubernetes/issues/85320#issuecomment-558784705. The impact is that a prebound PVC could take up to 30 seconds to bind.

**What you expected to happen**:
Ideally, the PV controller shouldn't intentionally race with itself.

**How to reproduce it (as minimally and precisely as possible)**:
Create a PVC that is prebound to a PV. Sometimes it will take a long time to finally bind. The VolumeBinding integration test was often flaking due to this.

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`):
- Cloud provider or hardware configuration:
- OS (e.g: `cat /etc/os-release`):
- Kernel (e.g. `uname -a`):
- Install tools:
- Network plugin and version (if this is a network-related bug):
- Others:
Repository: kubernetes
Issue: Do we still need PV controller resync?
Labels: kind/bug,sig/storage,lifecycle/frozen

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->


**What happened**:
Semi related to https://github.com/kubernetes/kubernetes/issues/85659. The PV controller resync of 15 seconds ends up hiding problems in the PV controller. The resync also causes a lot of churn, which can be problematic if you have a lot of PVs in your cluster.

**What you expected to happen**:
Is it worth trying out some experiments/tests to get rid of the frequent resyncs and fix the resulting bugs that come out of it?

**How to reproduce it (as minimally and precisely as possible)**:

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`):
- Cloud provider or hardware configuration:
- OS (e.g: `cat /etc/os-release`):
- Kernel (e.g. `uname -a`):
- Install tools:
- Network plugin and version (if this is a network-related bug):
- Others:
Repository: flutter
Issue: [camera] Allow custom resolution and aspect ratio
Labels: c: new feature,customer: crowd,p: camera,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

there are only 5 enum selections.and we can not customize the size of picture which i take.
i want to get a pic with low's 320*240 (4:3) and high quality.but i can not make it. Why the resolution and aspect ratio should be bound together, how to set them separately and take photos of various quality with specific aspect ratio
Repository: go
Issue: x/arch/x86/x86asm: missing Control-flow Enforcement instructions; e.g. ENDBR64
Labels: NeedsInvestigation

As a follow-up of #18665, instructions related to *Control-flow Enforcement* are currently not recognized by the `x/arch/x86` disassembler.

Example link at play.golang.org: https://play.golang.org/p/xz6V8cSREWF

```go
package main

import (
	"fmt"

	"golang.org/x/arch/x86/x86asm"
)

func main() {
	// ref: Section 7.1: ENDBR64 of "Control-flow Enforcement Technology Specification"
	//
	// https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
	text := []byte{0xF3, 0x0F, 0x1E, 0xFA} // endbr64
	inst, err := x86asm.Decode(text[:], 64)
	if err != nil {
		panic(err)
	}
	fmt.Println("inst:", inst)
	// Expected: ENDBR64
	// Got:      REP Op(0)
}
```

At rev golang/arch@368ea8f32ffff9e0bf2bf9b8c7f6dc5c2f5f6cfd, the `ENDBR64` instruction is incorrectly recognized as `REP Op(0)` without reporting any error from decode. The `ENDBR64` instruction has the byte sequence `0xF3, 0x0F, 0x1E, 0xFA` and was introduced as part of the *Control-flow Enforcement Technology Specification*: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

/cc: @rsc @minux
Repository: go
Issue: path/filepath: Walk walks through the same dir over and over again on build with gomobile iOS
Labels: NeedsInvestigation,mobile

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.4 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/macuser/Library/Caches/go-build"
GOENV="/Users/macuser/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/macuser/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Library/Golang/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Library/Golang/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/macuser/0chain/zboxcli/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5v/kc5tdz2506gf8tgp_kyk2kx00000gp/T/go-build973215397=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
Created a go library that uses filepath.Walk(). Works as expected with go application build using this library. The same library created using "gomobile bind -target=ios", with a Mac app, walks through the same dir over and over again and application crashes due to too much heap usage. 


### What did you expect to see?
Mac app hould work similar to go application.


### What did you see instead?
Recursive call and application crash. I works well with gomobile 1.12.7
Repository: go
Issue: x/build/cmd/gerritbot: sometimes fails to close PR after its imported CL is submitted
Labels: help wanted,Builders,NeedsFix

We should investigate why gerritbot didn't close a PR that was imported into Gerrit as a CL and submitted. 

- PR #35751
    - imported as [CL 208318](https://golang.org/cl/208318)

See https://github.com/golang/go/pull/35751#issuecomment-558859722 for more details.

Thanks @odeke-em for noticing and reporting.
Repository: youtube-dl
Issue: Site Request:  EPTV www.europarl.europa.eu/ep-live/
Labels: site-support-request

## Checklist
- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version 2019.11.22
- [ ] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs
- Single video: https://www.europarl.europa.eu/ep-live/en/plenary/video?debate=1574790135809

## Description
Those are live transmissions/recordings of european union parliament plenary sessions, so I guess it would be great to have, especially since it has links to specific discussions.
Plugin description and page source mentions QuickTime and Windows Media Player plugin.
https://web.archive.org/web/20170210185817/https://www.europarl.europa.eu/ep-live/en/help
Repository: pytorch
Issue: Adding a function to change the process_group in DistributedDataParallel
Labels: oncall: distributed,triaged

## 🚀 Feature
Adding a function to change the `process_group `in `DistributedDataParallel`

## Motivation
In current Pytorch, once `DistributedDataParallel `is initialized, `process_group ` will be fixed if I understand correctly. But sometimes different  `process_groups ` might be in need for different iterations.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528
Repository: terminal
Issue: Hebrew char taf ת (accessible by comma key on hebrew keyboard) appears in settings
Labels: Help Wanted,Issue-Bug,Area-UserInterface,Product-Terminal,Priority-3

# A quick note:

First off, loving v. 0.7. Secondly, this is a ridiculously minor bug that I haven't been able to even reproduce on my own machine. Don't really bother fixing it, I guess. But it's still undefined behavior, and I thought you might want to know that something like this can happen.

# Environment

```none
Windows: Microsoft Windows [Version 10.0.18362.476]
Windows Terminal version (if applicable): 0.7.3291.0

Any other software?
```

# Steps to reproduce

Not sure, haven't been able to reproduce it myself.

# Expected behavior

Should be Ctrl+comma displayed, IIRC.

# Actual behavior

A quick note: the character here, the hebrew letter taf - ת, is comma on the hebrew keyboard

![image](https://user-images.githubusercontent.com/16987694/69706278-0fbdf180-1100-11ea-87b7-e15cffb6e8e1.png)
Repository: kubernetes
Issue: Refactor kubelet with node status plugin and registry
Labels: sig/node,kind/feature,lifecycle/frozen

<!-- Please only use this template for submitting enhancement requests -->

**What would you like to be added**:

Part of https://github.com/kubernetes/kubernetes/issues/84681

Add node status `Plugin` and `Registry` for node status functions registration.

```go
// Plugin is the node status plugin which update the node's
// status.
type Plugin interface {
	// Name is the name of the plugin.
	Name() string

	// Update updates the status of the node.
	Update(node *v1.Node) error
}
```

Plugin registry is responsible for storing plugins and preserving the executing order. 

```go
var (
	pluginsOrdering = []string{"NodeAddress"}
)

// Registry preserves the invoking order of node status plugin.
type Registry struct {
	plugins map[string]Plugin
}

// NewRegistry returns a node status plugin registry.
func NewRegistry() *Registry {
	return &Registry{
		plugins: map[string]Plugin{},
	}
}

// Register appends a plugin to the registry.
func (r *Registry) Register(plugin Plugin) {
	r.plugins[plugin.Name()] = plugin
}

// UpdateNode updates node.
func (r *Registry) UpdateNode(node *v1.Node) {
	for _, pluginName := range pluginsOrdering {
		plugin, ok := r.plugins[pluginName]
		if !ok {
			continue
		}

		klog.V(5).Infof("Setting node status with plugin %s", pluginName)

		if err := plugin.Update(node); err != nil {
			klog.Errorf("Failed to set some node status fields: %s", err.Error())
		}
	}
}
```

**Why is this needed**:

Some components of the kubelet depend on the `GetNode` function of kubelet, and `GetNode` function has a complicated process which finally depends on the components of kubelet and causes circular dependency.

With the node status plugin and registry, we could create the node status registry before the creation of the kubelet and register plugins after the initialization.

After we create the node status registry and convert all the node status functions to plugins, we could make a new struct to provide the `GetNode` function and start to break the dependency here

https://github.com/kubernetes/kubernetes/blob/ee81b306815268cfbc01501f9dae12ce38974405/pkg/kubelet/kubelet.go#L559-L562

The process of migration wouldn't break the code or any unit tests and could be done by trunks.

**TODOs**:

+ [ ] Initialize the node status plugin interface https://github.com/kubernetes/kubernetes/pull/85665

/sig node
Repository: go
Issue: cmd/cover: support -mod and other build flags
Labels: NeedsFix,modules

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes, it does


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dionysius/.cache/go-build"
GOENV="/home/dionysius/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/dionysius/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build322712138=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->

GO_PATH/~/go/pkg/mod/ dir is empty
<pre>
$go tool cover -html=../coverage.cov -o ../coverage.html
</pre>

### What did you expect to see?
After running the cover command GO_PATH/~/go/pkg/mod/ dir is still empty


### What did you see instead?
After running the cover command GO_PATH/~/go/pkg/mod/ dir is not empty
Repository: terminal
Issue: Pane split vertically is different on non-English keyboard layouts
Labels: Issue-Docs,Needs-Tag-Fix

I'm using an English/US Windows 10 Pro 18362 with Danish keyboard layout. And the short cut for pane split vertically is Alt + Shift + "+"
Repository: rust
Issue: thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: DistinctSources(DistinctSources
Labels: I-ICE,E-needs-test,T-compiler,C-bug

Compiler panics. Debugging info attached. I would expect the compiler not to crash and print an error. 
[out.txt](https://github.com/rust-lang/rust/files/3896340/out.txt)
Repository: bitcoin
Issue: rfc: store PSBTs in wallet 
Labels: Feature,Brainstorming,Wallet

Now that #16944 has landed the GUI can create a PSBT and put it on the clipboard. The user can then use this with e.g. [HWI](https://github.com/bitcoin-core/HWI):

```
hwi --fingerprint=00000000 signtx 
```

But if something goes wrong and clipboard loses the PSBT, they have to start over.

#17509 adds support saving the PSBT to disk. Currently it only uses binary format, but it's easy to add base64 too, as @gwillen did in #16954.  Problem then is: if the user chooses the wrong format, they have to create the transaction all over again.

I propose that we store PSBTs in the wallet. They would show up in the transaction tab with some icon to indicate that they're incomplete. The user can copy them to clipboard or save to disk whenever they like. It should also be possible to delete them.

When a user loads a PSBT (e.g. via #17509) we should match it against what's in the wallet, and automagically join it. When a PSBT is complete it can be broadcast, deleted from the wallet, replaced by the regular transaction. All these steps should probably prompt for permission.

Slightly more advanced: PSBTs could keep coins locked by default (which incidentally creates a convenient way to persist locked coins, though there's other was to do that).
 
This is probably most useful for the GUI, but we could also support this with a few new RPC methods like `listwalletpsbts` (bash autocompletion ftw #17289). This also saves applications like [Specter](https://github.com/cryptoadvance/specter-desktop) (@stepansnigirev) and [Junction](https://github.com/justinmoon/junction) (@justinmoon) from having to build their own pseudo-wallet, when dealing with air gapped wallets.
Repository: godot
Issue: Incorrect GridMap cursor offset in 3D Half Resolution view
Labels: bug,topic:editor,confirmed,topic:3d

**Godot version:**
3.2 beta 2 official

**OS/device including version:**
macOS Catalina 10.15.1

**Issue description:**
When "Half Resolution" option is enabled in the 3D view settings, the GridMap offsets the cursor by 2x from the top-left of viewport.

![2019-11-27 13 55 32](https://user-images.githubusercontent.com/1460122/69717935-1f4c3300-111e-11ea-947d-919e26821572.gif)

**Steps to reproduce:**
1. Add a GridMap
2. Enable "Half Resolution" in 3D view settings
3. Try to paint on the GridMap
Repository: vscode
Issue: Api for editor insets
Labels: feature-request,api-proposal,editor-insets

This issue track the API proposal for editor insets. The current proposal is this

https://github.com/microsoft/vscode/blob/ffe3749d5afb046f289d04f915d8d4ade47c028e/src/vs/vscode.proposed.d.ts#L135-L147
Repository: electron
Issue: Publish a list of Electron dependencies
Labels: enhancement :sparkles:,documentation :notebook:

<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
<!-- Is your feature request related to a problem? Please add a clear and concise description of what the problem is. -->
I am not able to find a list of Electron dependencies for Linux. Can it be gathered and published? There is a speculation that the list consists of:

```
"gconf2", "gconf-service", "libnotify4", "libappindicator1", "libxtst6", "libnss3"
```

However, I don't think this list has been revised in a long time.

### Proposed Solution
<!-- Describe the solution you'd like in a clear and concise manner -->
Publish the official list of dependencies

### Alternatives Considered
<!-- A clear and concise description of any alternative solutions or features you've considered. -->

### Additional Information
<!-- Add any other context about the problem here. -->
Repository: rust
Issue: Print address on SIGSEGV
Labels: A-runtime,E-hard,T-libs-api,C-feature-request

It can be useful while debugging to find out if it is a null pointer / `NonNull::dangling()` pointer, or if it points just enough past the stack guard to not be detected as stack overflow.

It would also be useful to print if the access was a read, write or execution.
Repository: godot
Issue: Connections to Method doesn't update
Labels: bug,topic:editor,confirmed

**Godot version:**
3.2.beta2

**OS/device including version:**
Solus 4 Gnome

**Issue description:**

When disconnecting signals from a method using the editor interface they still show up in the **signals connected to method** interface. Even after saving the scene. They only update after reopening the scene.

![image](https://user-images.githubusercontent.com/10171059/69729607-60841900-1105-11ea-866d-8e3a14a01423.png)

![image](https://user-images.githubusercontent.com/10171059/69729679-890c1300-1105-11ea-8afa-1740b134f81d.png)


**Steps to reproduce:**

- Create a new scene
- Add some Nodes (2+)
- Attrach a script to one of them
- Connect the signal from the other Node to the Node with a script
- Check the **Connections to Method** interface
- Disconnect the signal
- Save
- Check the **Connections to Method** interface again
Repository: go
Issue: x/tools/go/packages: needs more explanations and examples
Labels: Documentation,NeedsInvestigation,Tools

Edit: It looks I used this package wrongly. On the other hand, I think the docs of this package is lack of detailed explanations and examples. I converted this issue to a document enrichment request. For examples, what are "the package as compiled for the test" and "the test binary". And some command line argument examples may be helpful.

And is the paragraph problematic?
> As noted earlier, the Config.Mode controls the amount of detail reported about the loaded packages, with each mode returning all the data of the previous mode with some extra added. See the documentation for type LoadMode for details.

Is it intended to explain the deprecated LoadFiles<LoadImports<LoadTypes<LoadSyntax<LoadAllSyntax preset modes?



(The following is the old content)
-----

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

```golang
package main

import (
    "fmt"
    "time"
    
    "go/ast"
    "go/parser"
    "go/token"

    "golang.org/x/tools/go/packages"
)

func main() {
	pkgs, err := packages.Load(nil, "std")
	if err != nil {
		panic(err)
	}

	var configForParsing = &packages.Config{
		Mode: packages.NeedName | packages.NeedImports | packages.NeedTypes |
			packages.NeedDeps | packages.NeedExportsFile | packages.NeedFiles |
			packages.NeedCompiledGoFiles | packages.NeedTypesSizes |
			packages.NeedSyntax | packages.NeedTypesInfo,
		Tests: false,

		ParseFile: func(fset *token.FileSet, parseFilename string, _ []byte) (*ast.File, error) {
			var src interface{}
			mode := parser.ParseComments // | parser.AllErrors
			file, err := parser.ParseFile(fset, parseFilename, src, mode)
			if file == nil {
				return nil, err
			}
			for _, decl := range file.Decls {
				if fd, ok := decl.(*ast.FuncDecl); ok {
					fd.Body = nil
				}
			}
			return file, nil
		},
	}

	parsedPkgs := make([]*packages.Package, 0, 1000)
	for _, pkg := range pkgs {

		fmt.Println(pkg.PkgPath)
		
		pkgs, err := packages.Load(configForParsing, pkg.PkgPath)
		if err != nil {
			fmt.Println("packages.Load error:", err)
		}
		parsedPkgs = append(parsedPkgs, pkgs...)
	}
	
	fmt.Println("[done]")
    
	for {
		time.Sleep(time.Hour)
	}
	
	fmt.Println(parsedPkgs)
}
```

### What did you expect to see?

<1G memory is consumed.

### What did you see instead?

7G memory is consumed.

Initially I posted this result here: https://groups.google.com/forum/#!topic/golang-tools/cLIwae8rx1g
Alan Donovan said this is not normal and Josh Bleecher Snyder suggested me post an issue here, so I do.
Repository: vscode
Issue: Debug: call stack commands arguments 
Labels: debug,debt

We need to do a couple of things:
1. Currently for commands which are contributed for threads we pass the `threadId` as a `number` argument. However this is not enough when you are debugging multiple sessions. Since the `threadId` does not uniquly identify the thread across sessions. Due to that we should send a structured object which contains the sessionId and the threadId
2. For `stackFrame` we pass the source uri string. Which is also not enough to identify the stackFrame. It should laso include the threadId and the sessionId
3. We need to add documention which explains what contexts we pass for contributed call stack commands

We will probably try not to break the current behavior, but add additional arugments after the current argument.

@testforstephen is Java contributing call stack commands for threads?
@roblourens @connor4312 fyi since the node debugging contribues Skip File commands
@weinand fyi