sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: youtube-dl
Issue: Full support for BFI free content
Labels: site-update-request

## Please follow the guide below

- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your *issue* (like this: `[x]`)
- Use the *Preview* tab to see what your issue will actually look like

---

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2019.02.08*. If it's not, read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2019.02.08**

### Before submitting an *issue* make sure you have:
- [x] At least skimmed through the [README](https://github.com/rg3/youtube-dl/blob/master/README.md), **most notably** the [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
- [x] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [x] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

### If the purpose of this *issue* is a *site support request* please provide all kinds of example URLs support for which should be included (replace following example URLs by **yours**):
- Single video: https://player.bfi.org.uk/free/film/watch-ian-dury-1983-online
- Single video: https://player.bfi.org.uk/free/film/watch-computer-doctor-1974-online
- Playlist: https://player.bfi.org.uk/free/collection/disabled-britain-on-film
- Homepage of free content: https://player.bfi.org.uk/free

Note that **youtube-dl does not support sites dedicated to [copyright infringement](https://github.com/rg3/youtube-dl#can-you-add-support-for-this-anime-video-site-or-site-which-shows-current-movies-for-free)**. In order for site support request to be accepted all provided example URLs should not violate any copyrights.

---

### Description of your *issue*, suggested solution and other information

Explanation of your *issue* in arbitrary form goes here. Please make sure the [description is worded well enough to be understood](https://github.com/rg3/youtube-dl#is-the-description-of-the-issue-itself-sufficient). Provide as much context and examples as possible.
If work on your *issue* requires account credentials please provide them or explain how one can obtain them.
Repository: go
Issue: meta: request output of `go list -m all` in the issue template
Labels: NeedsFix,Community

As @FiloSottile notes in https://github.com/golang/go/issues/30241#issuecomment-463829083:

> I actually don't want to have to figure out if a `crypto/tls` internal failure is due to a `replace`d `chacha20poly1305`.

But of course the same is true for `x`-repo interdependencies in general: if someone is reporting an issue against, say, `x/tools` or `x/net`, it would be really helpful to know the exact version in which they found the issue, and whether any of the dependencies involved have been locally modified.

I propose that we request `go list -m all` alongside `go env` in the issue template.

(CC @thepudds @myitcv @bradfitz)
Repository: create-react-app
Issue: Source License notice strip
Labels: issue: bug

I have a project, for example:

<details>
<summary>Example</summary>
<br/>
package.json

```json
{
  "...": "",
  "main": "index.js",
  "scripts": {
    "...": "",
    "build": "react-scripts build"
  },
  "dependencies": {
    "...": "",
    "react-scripts": "2.1.5"
  }
}
```

index.js
```js
/*!
 * project
 * Copyright 2019 Igor Vuchastyi
 * Licensed under MIT
 */

// Some other code
```

</details>
<br/>
When i run <code>npm run build</code> it executes <code>react-scripts build</code>, then it creates build directory like this build/static/{css,js}/*.{css,js}.<br/>
JS files doesn't contain any license i have specified at the index.js. If i do it with webpack - webpack collect my license and put at the top of bundle.
<br/><br/>
I think <b>react-scripts</b> strips my license from bundle and from other packages.
<br/><br/>
<b>My problem</b>: i don't want use <code>react-scripts eject</code>, i don't want use any other which is forks of react-scripts or etc.<br/>
<b>My question</b>: is there a way to leave my License notice at top of each chunk produced by react-scripts?<br/>
I was searching for around 2 hours. Was googling, was searching in this repository. Found nothing about this thread.
Repository: flutter
Issue: Make FixedExtentScrollPhysics & FixedExtentScrollController usable with ordinary ListViews
Labels: c: new feature,framework,P2,team-framework,triaged-framework

`FixedExtentScrollPhysics` and `FixedExtentScrollController` are very handy classes for creating snapping scroll views but unfortunately these can only be used with the `ListWheelScrollView`, which enforces a carousel-like 3D-effect.
`FixedExtentScrollPhysics` and `FixedExtentScrollController` would be more useful, if you could use these with ordinary scrolling views.
Repository: pytorch
Issue: Global Second Order Pooling
Labels: todo,feature,triaged,module: pooling

Global Second Order Pooling is claimed to be better than Global Average Pooling, which is used in many networks. Producing covariance matrices as image representations, it has achieved state-of-the-art results in a variety of vision tasks. Few examples are as follows:

http://openaccess.thecvf.com/content_cvpr_2018/papers/Li_Towards_Faster_Training_CVPR_2018_paper.pdf
http://openaccess.thecvf.com/content_ICCV_2017/papers/Li_Is_Second-Order_Information_ICCV_2017_paper.pdf
https://vision.cornell.edu/se3/wp-content/uploads/2017/04/cui2017cvpr.pdf
https://arxiv.org/pdf/1804.00428.pdf
https://arxiv.org/abs/1611.02155

More importantly, in this (https://arxiv.org/pdf/1811.12006.pdf) paper, they also claim it to be better than several state-of-the-art spatial and channel attention modules (Squeeze-Excite, Gather-Excite, CBAM, etc). Some implementations are here. I believe that it would be great to have Global Second Order Pooling in the PyTorch framework with a reliable and fast implementation of the functionality required.

https://github.com/jiangtaoxie/fast-MPN-COV/blob/master/src/representation/MPNCOV.py
Repository: flutter
Issue: Autoselect real device when running in release mode
Labels: c: new feature,tool,a: quality,P2,team-tool,triaged-tool

If you have both a real device and a simulator connected, and you do `flutter run --release`, flutter asks you which device to run on, but it can only run on a real device in release mode, so could it not just autoselect the real device ( if it's possible to differentiate this ) ?
Repository: go
Issue: x/build/cmd/gerritbot: Gerrit asks PR author to review their own change
Labels: Builders,NeedsInvestigation

In https://go-review.googlesource.com/c/oauth2/+/162937 I wrote:

> I'm going to delete your code review vote because it's misleading. Reviewing your own code doesn't really count in terms of our code review requirements.

PR author @nwidger then replied:

> My bad!  I wasn't sure if doing that was appropriate.  The email from Gerrit Bot said 'Gerrit Bot would like Niels Widger to review this change' so I thought maybe that's what it wanted me to do.

This is a tracking bug to understand why that happened and ideally prevent that message.

/cc @andybons @dmitshur
Repository: TypeScript
Issue: Add '--bail' option when running '--build' mode
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms
project references, bail, cascade, errors
<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion
When building multiple Typescript projects using the `--build` flag, and the projects had dependencies on each other, an error in an upstream project can cause a cascade of errors from downstream projects that obscure the original error.

A possible solution would be a `--bail` option (or however you'd like to name it). When provided in `--build` mode, it would prevent all projects downstream from a project with an error from building. While this may hide downstream errors that are only found when re-running, it will prevent "false-positive" errors from being shown.
<!-- A summary of what you'd like to see added or changed -->

## Use Cases
Using `--build` mode on a large web of project references, without the possibility of being flooded with spurious errors due to one upstream typo.
<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: kubernetes
Issue: Kubelet sysctl settings cannot be overridden
Labels: area/kubelet,sig/node,kind/feature,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**:
The kubelet overrides user defined sysctl parameters silently.

**What you expected to happen**:
Values defined by the administrator in `/etc/sysctl.d/*.conf` files should take priority or at least not be silently overridden.

**How to reproduce it (as minimally and precisely as possible)**:
1. Create a file in `/etc/sysctl.d` that conflicts with one that kubelet sets on startup. - `echo "vm.panic_on_oom = 1" > /etc/sysctl.d/30-panic-on-oom.conf` is a good example.
2. Reboot
3. After boot the value specified through sysctl is overridden by kubelet.

**Anything else we need to know?**:
This behavior is particularly tricky to debug because the kubelet is almost always going to start after the systemd-sysctl service. The end result here is that the system boots and claims to have successfully applied all user defined kernel configuration, but then inspecting manually with the `sysctl` utility doesn't show the expected values.

I can understand why the kubelet would want to discover the state of the oom panic toggle on startup, but the changes made for #15091 appear to have completely hard-coded this behavior and actively fight against configuration managed through traditional Linux management options (these parameters would all be valid on the GRUB command line or through systemd setting sysctl parameters on startup). 

I can see a few options that would be a reasonable way to handle this:
1. Offer a configuration option on the kubelet to override the behavior.
2. Stop managing sysctl parameters that are not fatal to the kubelet running and ship recommended parameters as sysctl.d config files through post-install tooling for the kubelet package in a package manager (deb/rpm) or by letting provisioning tools create those files. Parameters that are considered best-practice but are not required for the kubelet to start can throw a warning.

**Environment**:
- Kubernetes version (use `kubectl version`): 1.12.4
- Cloud provider or hardware configuration: Azure
- OS (e.g. from /etc/os-release): Ubuntu 16.04
- Kernel (e.g. `uname -a`): `4.15.0-1037-azure`
- Install tools: AKS Engine
Repository: go
Issue: cmd/go: explicitly reject packages whose source files contain leading dots
Labels: OS-Darwin,NeedsInvestigation

### What version of Go are you using (`go version`)?
<pre>
go1.11.1 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes, tested with:
<pre>
go1.12rc1 darwin/amd64
</pre>
But at least the latest version shows the `._` filename being processed, and generates 'unexpected NUL in input'

### What operating system and processor architecture are you using (`go env`)?
```

GOARCH="amd64"
GOBIN="/Users/peter/go/bin"
GOCACHE="/Users/peter/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
```

### What did you do?
`go build`
### What did you expect to see?
module to build without errors, which it does after deleting the spurious `._<filename>.go` file.  

Probably the go command line tools should be ignoring these system files.
### What did you see instead?
fails with "cannot find package"
I initially thought this was related to #27238 but I think it is a different problem specific to macos.  However it might be worth adding a link from there in case anyone else has this problem.
Repository: pytorch
Issue: Deadlock with multiprocessing (using fork) and OpenMP / PyTorch should warn after OMP and fork that multithreading may be broken
Labels: high priority,module: docs,module: multiprocessing,triaged

## 🐛 Bug

The following program never terminates.

```
import torch
import torch.multiprocessing as mp


def foo():
    x = torch.ones((2, 50, 10))
    return torch.einsum('ijl,ikl->ijk', x, x)


if __name__ == '__main__':
    foo()
    p = mp.Process(target=foo)
    p.start()
    p.join()
```

The behavior persists if one changes the `einsum` inside `foo` with an equivalent operation (e.g., `bmm(y, y.transpose(1,2))`, or `(y.unsqueeze(2) * y.unsqueeze(1)).sum(3)`.

It doesn't reproduce, however, if one doesn't call `foo` inside the main block.

## Environment

PyTorch version: 1.0.1.post2
Is debug build: No
CUDA used to build PyTorch: 9.0.176

OS: Arch Linux
GCC version: (GCC) 8.2.1 20181127
CMake version: version 3.13.4

Python version: 3.7
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

## Additional context

Perhaps related to #2245.
Repository: go
Issue: runtime: simplify right shift and zero test
Labels: Performance,NeedsFix,compiler/runtime

### What version of Go are you using (`go version`)?

1.11

### What did you do?

Please consider the following dummy code:

    func Dummy(x uint64) int {
        i := 0
        for {
            x >>= 1
            if x == 0 {
                break
            }
            i -= 1
        }
        return i
    }

### What did you expect to see?

Main part of the loop could compile down to (i.e. without the test for zero):

    SHRQ $1, AX
    JNE label

or even:

    SHRQ AX
    JNE label

### What did you see instead?

It compiles down to (on x86):

    SHRQ $1, AX
    TESTQ AX, AX
    JNE label

PS: I've just noticed similar situation occurs with `- 1`, instead of `>> 1`:

    func DummySub(x int64) int {
        if x == 0 {
            x = 10
        }
        i := 0
        for {
            x -= 1
            if x == 0 {
                break
            }
            i += 1
        }
        return i
    }

There the:

    DECQ AX
    CMPQ AX, $1
    JNE label

could also be replaced by:

    SUBQ AX, $1 // or DECQ AX
    JE label
Repository: rust
Issue: Type inference fails even though all types are known
Labels: P-medium,T-compiler,regression-from-stable-to-stable,A-inference,C-bug

The following code fails to compile, even though all types are known
https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=8de9e57e8de5cd8f2896f422d693f453

```rust
pub fn f(s: &str) {
    let mut it = s.split(|c: char| c == ',').fuse();
    let t = it.next().unwrap().parse::<usize>().unwrap();
}
```
```
   Compiling playground v0.0.1 (/playground)
error[E0282]: type annotations needed
 --> src/main.rs:3:13
  |
3 |     let t = it.next().unwrap().parse::<usize>().unwrap();
  |             ^^^^^^^^^^^^^^^^^^ cannot infer type for `T`
  |
  = note: type must be known at this point

error: aborting due to previous error

For more information about this error, try `rustc --explain E0282`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.
```
Repository: rust
Issue: Tracking issue for error source iterators
Labels: T-libs-api,B-unstable,C-tracking-issue,A-error-handling,Libs-Tracked,PG-error-handling

This covers the `<dyn Error>::iter_chain` and `<dyn Error>::iter_sources` methods added in #58289.
Repository: rust
Issue: Poor suggestions wrt closure type/lifetime inference
Labels: C-enhancement,A-diagnostics,A-closures,T-compiler,A-inference,A-suggestion-diagnostics,D-newcomer-roadblock

Given the following code:

```
fn main() {
    let cl = |x| { x.split_at(0) };
    let (_x, _y) = cl("42");
}
```

rustc suggests:
```
3 |     let cl = |x| { x.split_at(0) };
  |               ^ consider giving this closure parameter a type
```

Unfortunately, specifying a closure parameter type casts the user from the frying pan into the fire:
```
error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
 --> src/main.rs:3:27
  |
3 |     let cl = |x:&str| { x.split_at(0) };
  |                           ^^^^^^^^
  |
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the body at 3:14...
 --> src/main.rs:3:14
  |
3 |     let cl = |x:&str| { x.split_at(0) };
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...so that reference does not outlive borrowed content
 --> src/main.rs:3:25
  |
3 |     let cl = |x:&str| { x.split_at(0) };
  |                         ^
note: but, the lifetime must be valid for the call at 4:20...
 --> src/main.rs:4:20
  |
4 |     let (_x, _y) = cl("42");
  |                    ^^^^^^^^
note: ...so type `(&str, &str)` of expression is valid during the expression
 --> src/main.rs:4:20
  |
4 |     let (_x, _y) = cl("42");
  |                    ^^^^^^^^
```

Helpful contributors on #rust-beginners found https://github.com/rust-lang/rust/issues/55526 https://github.com/rust-lang/rust/issues/56537 and the following simple workaround:

```
fn main() {
    let cl = |x| { let x : &str = x; x.split_at(0) };
    let (_x, _y) = cl("42");
}
```

The underlying problem with lifetime inference in closures seems quite tricky and I guess it will remain like this for a while.

Under the circumstances, it would be nice if the compiler could make more helpful suggestions, including the trick with the let binding to nail the type.

Something like this maybe:

> Consider removing the type specification for this closure parameter to allow lifetime inference.  If the type specification is needed within the closure, a binding  let VAR : TYPE = VAR  at the start of the closure may help.

(for outputting, in addition to the other messages, in the more complicated lifetime problem case)
Repository: pytorch
Issue: Group Norm Error When using FP16
Labels: needs reproduction,triaged,module: type promotion,module: half,module: norms and normalization

## 🐛 Bug

## To Reproduce
```
import torch
x = torch.randn(1, 10, 20, 20).cuda().half()
M1 = torch.nn.BatchNorm2d(10).cuda()
M2 = torch.nn.GroupNorm(10, 10).cuda()
M1(x)  (tensor)
M2(x)  (error)
```
```
RuntimeError: Expected object of scalar type Float but got scalar type Half for argument #3 'tensor1'
  ```

## Expected behavior
Group norm seems to reshape the input tensor and then use batch norm internally based on [these lines]:(https://github.com/pytorch/pytorch/blob/7157be86226b79e3a698cbb0c524fc3ae59e28de/aten/src/ATen/native/Normalization.cpp#L465)

```
# ATen/native/Normalization.cpp

auto input_reshaped = input.contiguous().view({1, b * num_groups, -1});

    auto out = at::batch_norm(input_reshaped, {}, {}, {}, {}, true, 0, eps,
                              cudnn_enabled);
out = out.view(input_shape);
```
I am able to train models that have batch norms in mix precision with Nvidia's [apex](https://github.com/NVIDIA/apex), so I guess it should work for group morns. 


## Environment

PyTorch version: 1.0.1
Is debug build: No
CUDA used to build PyTorch: 10.0
OS: Microsoft Windows 10 Home
GCC version: (GCC) 7.3.0
CMake version: version 3.12.18081601-MSVC_2
Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.0.130




cc @nairbv @mruberry
Repository: rust
Issue: Impossible to specify link-args for lld in json target specification
Labels: C-enhancement,T-compiler,A-target-specs

Rustc target spec json files can specify `link-args` and `pre-link-args`. For instance, here is part of the output of `rustc -Z unstable-options --print target-spec-json --target i686-unknown-linux-gnu`:

```json
  "pre-link-args": {
    "gcc": [
      "-Wl,--as-needed",
      "-Wl,-z,noexecstack",
      "-m32"
    ]
  },
```

As far as I can tell, for annoying reasons about how it's implemented, it isn't possible to set this with `lld` instead of `gcc`.

In [`librustc_target/spec/mod.rs`](https://github.com/rust-lang/rust/blob/master/src/librustc_target/spec/mod.rs):

```rust
#[derive(Clone, Copy, Debug, Eq, Ord, PartialEq, PartialOrd, Hash,
         RustcEncodable, RustcDecodable)]
pub enum LinkerFlavor {
    Em,
    Gcc,
    Ld,
    Msvc,
    Lld(LldFlavor),
    PtxLinker,
}
```

This is serialized and de-serialized with `rustc-serialize`. Unlike the other variants, `Lld` contains a field. Looking at how the json serialization/de-serialization is [implemented](https://github.com/rust-lang-deprecated/rustc-serialize/blob/master/src/json.rs), it looks like this is would be represented as `{"variant": "lld", "fields": [...]"}`.

The issue is that this can't appear in the target spec in place of `"gcc"` from the example above, since json doesn't allow an object to be the key of an object.

Is my analysis right, and this is currently impossible to do in a json target spec, or am I missing something?

### Solution
I think the best solution in the short term is to implement `Decodable` and `Encodable` manually for the enum. I presume changing the representation of this wouldn't break anything in practice, and even if it did it's an implementation detail that doesn't provide stability guarantees?

In the long term, I'm not sure what the plans for `rustc-serialize` are. It describes itself as "deprecated". Is it ideally intended to be replaced with `serde` at some point, which just hasn't been done since it's a lot of work?