sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: net/http: incorrectly redirect (301) if request payload include port number
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.18 linux/arm64
</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="arm64"
GOBIN=""
GOCACHE="/home/admin/.cache/go-build"
GOENV="/home/admin/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/admin/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/admin/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/admin/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3281198030=/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 go.dev/play is best.
-->
**server.go**
```
package main

import (
	"io"
	"log"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		io.WriteString(w, "hello world")
	})

	log.Fatal(http.ListenAndServe(":80", nil))
}
```

**client.go**
```
package main

import (
	"bufio"
	"fmt"
	"io"
	"log"
	"net"
)

func main() {
	// conn, err := net.Dial("tcp", "1.1.1.1:80")
	conn, err := net.Dial("tcp", "127.0.0.1:80")
	if err != nil {
		log.Fatal(err)
	}
	defer conn.Close()

	var payload = "GET localhost:80 HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n\r\n"

	_, err = conn.Write([]byte(payload))
	if err != nil {
		log.Fatal(err)
	}

	reader := bufio.NewReader(conn)

	for {
		message, err := reader.ReadString('\n')
		fmt.Print(message)

		if err == io.EOF {
			break
		}
	}
}
```


### What did you expect to see?
HTTP/1.1 400 Bad Request


### What did you see instead?
HTTP/1.1 301 Moved Permanently
Repository: pytorch
Issue: OpInfo request for `nn.functional` and `unbind`
Labels: high priority,module: tests,triaged

### 🚀 The feature, motivation and pitch

Please add the following OpInfos
- [x] nn.functional.binary_cross_entropy_with_logits https://github.com/pytorch/pytorch/pull/75604
- [x] nn.functional.binary_cross_entropy (https://github.com/pytorch/pytorch/pull/75782)
- [x] nn.functional.smooth_l1_loss (https://github.com/pytorch/pytorch/pull/75782)
- [ ] nn.functional.dropout3d (and dropout2d while you’re at it)
- [ ] unbind
- [ ] nn.functional.conv3d (and conv1d while you’re at it)
- [ ] nn.functional.multi_head_attention_forward
- [x] nn.functional.l1_loss  (https://github.com/pytorch/pytorch/pull/75782)

Why? These are some of the more commonly used PyTorch operations that do not have OpInfos. Adding the OpInfo means that all the PyTorch subsystems that use OpInfo-based tests (autograd, meta tensors, functorch, to name a few) will automatically get test coverage for them!

We are happy to give prioritized reviews for the above (tag me as a reviewer).

### Alternatives

n/a

### Additional context

n/a

cc @ezyang @gchanan @zou3519 @mruberry
Repository: nvm
Issue: macOS: Webstorm, Intellij, all Jetbrains Products environment failure from nvm.sh after reboot
Labels: performance

For other users of Jetbrains products, I finally got to the bottom of this annoying message that seems to pop up only after full system reboot (before opening a terminal). After painstakingly going through every line of my .zprofile, .zshrc, .zshenv, commenting, uncommenting, rebooting, I found it... `nvm.sh`. Of course it's node related!

<img width="687" alt="Screen Shot 2022-03-23 at 9 26 14 AM" src="https://user-images.githubusercontent.com/1032983/159715705-83a35f05-2104-443f-8d86-dacf711811f7.png">

It seems something about `nvm.sh` (permissions, prompts, errors, etc) interferes with Jetbrains shell extension loader due to "interactive shell", see https://youtrack.jetbrains.com/articles/IDEA-A-19/Shell-Environment-Loading.

Trying to fix as suggested by Jetbrains doesn't work through...
```sh
# DOES NOT WORK
if [ -z "$INTELLIJ_ENVIRONMENT_READER" ]; then
	[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # <---  problem
	[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  
fi
```

I've got about 5 hours into finding this bug now -- hopefully someone who knows shell better than me can figure out what in nvm.sh is causing this issue. Reproduce with macOS 12.3, latest nvm freshly curled today, rm -rf node, yarn, all the symlinks, yadda yadda. Also posting on Youtrack so they can point others to comment out nvm.sh loads.
Repository: rust
Issue: `std::fs::canonicalize` fails to resolve `/dev/stdin` connected to pipe
Labels: C-bug,T-libs,A-io,O-unix

When program tries to canonicalizes `/dev/stdin` it should resolve to `tty`, `pipe` or `file` as per configured redirection
I tried this code and attached a pipe to stdin:
```rust
use std::fs;

fn main() {
    let resolved_path = fs::canonicalize("/dev/stdin").unwrap();
    println!("{}", resolved_path.into_os_string().into_string().unwrap());
}
```
```shell
echo " " | cargo run
```
I expected to see this happen: `/dev/stdin` canonicalizes to `/proc/14063/fd/pipe:[127582]`

Instead, this happened: 
```shell
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/canon-issue`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:4:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.59.0 (9d1b2106e 2022-02-23)
binary: rustc
commit-hash: 9d1b2106e23b1abd32fce1f17267604a5102f57a
commit-date: 2022-02-23
host: x86_64-unknown-linux-gnu
release: 1.59.0
LLVM version: 13.0.0
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/canon-issue`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:4:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

</p>
</details>

Same thing in `Python 3.9.7`

```python
import os
print(os.path.realpath("/dev/stdin"))
```
```shell
echo " " | python3 code.py
```
This is the result

```
/proc/16616/fd/pipe:[162072]
```
Repository: opencv
Issue: In-place checks are wrong
Labels: RFC

##### System information (version)
- OpenCV => 3.4 head

##### Detailed description

In a few places in the code, inplace processing is checked. E.g. https://github.com/opencv/opencv/blob/0a62de0d4f83d9789d16c23e1619074addad3b0b/modules/core/src/mathfuncs.cpp#L272 , https://github.com/opencv/opencv/blob/9d16612a9b028f03747037c74d9678ef72e95e85/modules/core/src/copy.cpp#L698 or https://github.com/opencv/opencv/blob/9d16612a9b028f03747037c74d9678ef72e95e85/modules/imgproc/src/color.cpp#L298
(there is more, just look for getObj())

For those checks, getObj is compared: getObj returns a `void*` to the original object that was used to create an InputArray/OutputArray. The proper way would be to compare the pointers to the raw data that those objects wrap.

##### Steps to reproduce

```
#include "opencv2/core.hpp"

int main(int, char**argv){

cv::Mat1d A[2] = {cv::Mat1d(10, 10), cv::Mat1d(10, 10)};
for(auto&a: A) cv::randu(a, 0, 10000);
// B points to the same data as A but is a different object.
cv::Mat1d B[2] = {A[0], A[1]};

cv::cartToPolar(A[0], A[1], B[0], B[1], false);
// No crash, all is fine even though B points to the same data as A.
}
```

##### Issue submission checklist

 - [x] I report the issue, it's not a question
 - [x] I checked the problem with documentation, FAQ, open issues,
       forum.opencv.org, Stack Overflow, etc and have not found any solution
 - [x] I updated to the latest OpenCV version and the issue is still there
 - [x] There is reproducer code and related data files: videos, images, onnx, etc
Repository: pytorch
Issue: __rpow__(self, other) OpInfo should not test the case where `other` is a Tensor
Labels: module: tests,triaged

### 🐛 Describe the bug

After https://github.com/pytorch/pytorch/pull/74280 (cc @mruberry), the `__rpow__` OpInfo has a sample input where `other` is a Tensor. This cannot happen during normal execution: to get to `Tensor.__rpow__` a user does the following:

```
# self = some_tensor
# other = not_a_tensor
not_a_tensor ** some_tensor
```
If instead `not_a_tensor` is a Tensor, this ends up calling `__pow__` in Python which will then handle the case.

Are there any legitimate cases where we do want this to happen?

## Context

This caused some functorch tests to fail because we don't support the route where both `self` and `other` are Tensors. pytorch/pytorch also has some cryptic warning in that route:
![image](https://user-images.githubusercontent.com/5652049/159735534-1f19bbad-0596-4577-8ced-d3a61c6a8bfd.png)

but it's not clear to me if we want to support this or not.

### Versions

pytorch main branch
Repository: rust
Issue: Unclear static lifetime message
Labels: A-diagnostics,A-lifetimes,T-compiler,D-confusing,D-terse

Given the following code ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=18b70dc967a80be7c93640e7fc09bb16)):

```rust
use std::io::Read;

struct Foo {
    inner: Option<Box<dyn Read>>,
}

impl Foo {
    fn member(&mut self) {
        bar(self.inner.as_deref_mut());
    }
}

fn bar(read: Option<&mut dyn Read>) {
    
}


fn main() {
  let mut foo = Foo { inner: None };
  foo.member();
}
```

The current output (on stable and nightly) is:

```
   Compiling playground v0.0.1 (/playground)
error[E0759]: `self` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement
 --> src/main.rs:9:24
  |
8 |     fn member(&mut self) {
  |               --------- this data with an anonymous lifetime `'_`...
9 |         bar(self.inner.as_deref_mut());
  |             ---------- ^^^^^^^^^^^^
  |             |
  |             ...is used and required to live as long as `'static` here

For more information about this error, try `rustc --explain E0759`.
error: could not compile `playground` due to previous error
```

I can't work out where the 'static lifetime requirement is coming from here.

Is it possible the compiler is confused by the multiple de-references here?

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Suggest adding a reference for `&[str]`, not just `str`
Labels: A-diagnostics,T-compiler,D-terse

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0682c1798c04ce89d5780a3124a755ea

```rust
fn f(x: &[str]) {}
```

The current output is:

```
error[E0277]: the size for values of type `str` cannot be known at compilation time
 --> src/lib.rs:1:10
  |
1 | fn f(x: &[str]) {}
  |          ^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `str`
  = note: slice and array elements must have `Sized` type
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0277]: the size for values of type `str` cannot be known at compilation time
 --> src/lib.rs:1:6
  |
1 | fn f(x: &[str]) {}
  |           ^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `str`
help: function arguments must have a statically known size, borrowed types always have a known size
  |
1 | fn f(x: &[&str]) {}
  |           +
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions. The output might also be
different depending on the Edition.
-->


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Confusing Error Message on Closure Argument Lifetimes
Labels: A-diagnostics,T-compiler,D-confusing

Hi all, I am getting a confusing error message when omitting the types of the arguments of a closure. This may be somewhere in between of a bug and a diagnostics issue, but I am not brave enough to suggest that the compiler should make a different decision here. :)

Given the following code: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=eedb8aa7428053e5108270963ea72e59)

```rust
use std::collections::BTreeMap;

fn my_retain(map: &mut BTreeMap<i32, i32>, pred: impl Fn(&i32) -> bool) {
    let pred_better = |_, val: &mut i32| {
        pred(val)
    };
    map.retain(pred_better);
}

fn main() {}
```

The current output is:

```
Compiling playground v0.0.1 (/playground)
error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
   [--> src/main.rs:7:15
](https://play.rust-lang.org/#)    |
7   |     mapperoni.retain(pred_better);
    |               ^^^^^^ lifetime mismatch
    |
    = note: expected type `FnOnce<(&i32, &mut i32)>`
               found type `for<'r> FnOnce<(&i32, &'r mut i32)>`
note: this closure does not fulfill the lifetime requirements
   [--> src/main.rs:4:23
](https://play.rust-lang.org/#)    |
4   |       let pred_better = |_, val: &mut i32| {
    |  _______________________^
5   | |         pred(val)
6   | |     };
    | |_____^
note: the lifetime requirement is introduced here
   --> /home/me/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/collections/btree/map.rs:977:33
    |
977 |         F: FnMut(&K, &mut V) -> bool,
    |                                 ^^^^

```
This is not very helpful, because the last `note` section doesn't point to a lifetime, it points to a bool. It probably means that &K and &mut V have elided lifetimes that should match, and the compiler had not decided to give the `pred_better` closure matching argument lifetimes.

Ideally the output should look like:

```
Compiling playground v0.0.1 (/playground)
error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
   [--> src/main.rs:7:15
](https://play.rust-lang.org/#)    |
7   |     mapperoni.retain(pred_better);
    |               ^^^^^^ lifetime mismatch
    |
    = note: expected type `FnOnce<(&i32, &mut i32)>`
               found type `for<'r> FnOnce<(&i32, &'r mut i32)>`
note: this closure does not fulfill the lifetime requirements, because you have not specified the second argument of the closure to be of type `&i32`, and therefore lifetime elision has not decided that the lifetimes of the closure should be the same.
help: consider specifying the argument types of the closure: |_: &i32, val: &mut i32|
```

I also think that maybe the compiler should infer what the correct lifetimes should be, since it can look at the definition of `BTreeMap::<i32, i32>::retain`, but I am not sure what the way forward is.

Behaviour happens with both nightly and stable
Repository: vscode
Issue: Find/Replace Input Box Font Change (`I` vs `l`)
Labels: polish,editor-find

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Find/Replace input box font does not easily distinguish between similar looking characters. e.g. Capital `I` and Lowercase `l`.  Perhaps have the find/replace input box font match that of the editor?  Or just pick a different font altogether that is easier to distinguish. 

This is useful when trying to ensure I have correctly typed the text I want to find and replace.
Repository: storybook
Issue: Custom mdx components not working when rendering `.md` files with `Description`
Labels: bug,mdx

**Describe the bug**

I have used some custom components in my `preview.js`. 

```
export const parameters = {
  docs: {
    components: {
      h1: Component,
      p: Component,
    },
  },
};
```

When I am trying to use the `Description` component to render my `README.md` in my storybook:

```mdx
import { Description, Meta } from '@storybook/addon-docs/blocks';

import readme from '../README.md';

<Meta title="Readme" />

<Description>
  { readme }
</Description>
```

I am not seeing the custom components being used for the `h1` and the `p`. Is there something I'm missing? Or is this a limitation of the `Description` component.
Repository: flutter
Issue: `Linux framework_tests_misc` flakes on `cupertino_action_sheet`
Labels: framework,f: cupertino,P2,c: flake,team-design,triaged-design

(part of https://github.com/flutter/flutter/issues/97036)

Linux framework_tests_misc: 1 flake on [cupertino_action_sheet failure](https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20framework_tests_misc/4028/overview)

```
00:18 +24: /b/s/w/ir/x/w/flutter/examples/api/test/cupertino/dialog/cupertino_action_sheet.0_test.dart: Perform an action on CupertinoActionSheet                                                      
Encountered an error trying to run "uname -m":
  exit code: 1664100400
  stdout: x86_64
  stderr: 
Assuming host platform is linux-x64.
```
Repository: pytorch
Issue: Feature request: INT4 format support
Labels: oncall: quantization,feature,triaged

### 🚀 The feature, motivation and pitch

Currently, pytorch officially supports INT8 format. However, recently, the newer GPUs (like T4/A100) already supports INT4 tensorcore. Meanwhile, from machine learning community, binary/ternary/int4 algorithms are well developed. It is the time to support lower INT format to connect research to product by Pytorch. I collaborated with Huggingface and Huggingface team is also looking for this feature as well. 

### Alternatives

_No response_

### Additional context

_No response_

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
Repository: node
Issue: History section of ECMAScript modules documentation is confusing
Labels: doc,esm

### Affected URL(s)

https://nodejs.org/docs/latest-v14.x/api/esm.html https://nodejs.org/docs/latest-v16.x/api/esm.html

### Description of the problem

Hello, the top-level history section of this documentation in the following versions include the following entries:

[12.x LTS documentation (v12.22.11)](https://nodejs.org/docs/latest-v12.x/api/esm.html):

| | |
| --- | --- |
| v12.22.0 | Stabilize modules implementation. |
| v12.20.0 | Remove experimental modules warning. |

[14.x LTS documentation (v14.19.1)](https://nodejs.org/docs/latest-v14.x/api/esm.html):

| | |
| --- | --- |
| v14.17.0 | Stabilize modules implementation. |
| v14.0.0, v13.14.0	| Remove experimental modules warning. |

[16.x LTS documentation (v16.14.2)](https://nodejs.org/docs/latest-v16.x/api/esm.html):

| | |
| --- | --- |
| v15.3.0, v12.22.0	| Stabilize modules implementation. |
| v14.0.0, v13.14.0, v12.20.0 | Remove experimental modules warning. |

When reading the v14 documentation it makes it sound like stabilizing the implementation first happened in v14.17.0 (and not in any 12.x version).

When reading the v16 documentation it makes it sound like stabilizing the implementation first happened in v12.22.0, and either would have been in v14.0.0 or not in any 14.x version.

I'd expect the history in each version to include the entries for lower versions. So in this case I'd expect the 14.x history to include the 12.x entries, and the 16.x history to include the 14.x and 12.x entries. But 14.x omits some of the 12.x stuff and 16.x omits some of the 14.x stuff (but includes the 12.x stuff).

The implementation was stabilized in v12.22.0, v14.17.0, and v16.0.0, right?

Also, how would you clearly be able to tell when something like "Stabilize modules implementation" was the case in an X.0.0 version? Like in the 16.x documentation, should it say ">= v15.3.0"?
Repository: vscode
Issue: Up arrow in python debug console does not work as expected after using "Evaluate in Debug Console"
Labels: bug,debug


Issue Type: <b>Bug</b>

Normally, pressing the up-arrow in the debug console brings up the last entered expression. However this seems to skip any expression coming from the `Evaluate in Debug Console" command. 

Admittedly not a huge issue, but a common workflow when debugging is evaluating an expression in the console, and then trying to get more information on that expression. Common example: if I selected a generator and do `Evaluate in Debug Console` , the result is an unhelpful `<generator object...`. Intuitively, I would then do up arrow and wrap it in `list()` to see what's inside, but that doesn't work, so I have to go back and copy paste the expression in the repl instead.



Extension version: 2022.2.1924087327
VS Code version: Code 1.65.2 (c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1, 2022-03-10T14:33:55.248Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No
Remote OS version: Linux x64 5.4.0-94-generic
Remote OS version: Linux x64 5.4.0-94-generic
Remote OS version: Linux x64 5.4.0-94-generic

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

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz (8 x 1896)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: enabled<br>opengl: enabled_on<br>rasterization: enabled<br>skia_renderer: enabled_on<br>video_decode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|15.88GB (5.69GB free)|
|Process Argv|--crash-reporter-id 89aeed25-8dc2-46ce-b17c-1f93ab95c565|
|Screen Reader|no|
|VM|0%|

|Item|Value|
|---|---|
|Remote|SSH: spidsmus.sdma.nzcorp.net|
|OS|Linux x64 5.4.0-94-generic|
|CPUs|Intel(R) Xeon(R) CPU E5-2687W v3 @ 3.10GHz (12 x 3092)|
|Memory (System)|58.87GB (1.94GB free)|
|VM|0%|

|Item|Value|
|---|---|
|Remote|SSH: spidsmus.sdma.nzcorp.net|
|OS|Linux x64 5.4.0-94-generic|
|CPUs|Intel(R) Xeon(R) CPU E5-2687W v3 @ 3.10GHz (12 x 3092)|
|Memory (System)|58.87GB (1.94GB free)|
|VM|0%|

|Item|Value|
|---|---|
|Remote|SSH: spidsmus.sdma.nzcorp.net|
|OS|Linux x64 5.4.0-94-generic|
|CPUs|Intel(R) Xeon(R) CPU E5-2687W v3 @ 3.10GHz (12 x 3092)|
|Memory (System)|58.87GB (1.94GB free)|
|VM|0%|
</details>
<!-- generated by issue reporter -->