internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: google/osv.dev

Issue:
Minor issues with Debian advisories revisited
This is directly related to the previous issue
https://github.com/google/osv.dev/issues/1525

This time `<unfixed>` versions seemed to be present, and I am unsure if this is expected. Perhaps just omitting the fixed version would be preferable?  
https://osv.dev/vulnerability/DSA-746-1
https://osv.dev/vulnerability/DSA-866-1
https://osv.dev/vulnerability/DSA-880-1




Discussion:
@another-rex can you take a look here? 

Resolving patch:
diff --git a/vulnfeeds/tools/debian/debian_converter/convert_debian.py b/vulnfeeds/tools/debian/debian_converter/convert_debian.py
--- a/vulnfeeds/tools/debian/debian_converter/convert_debian.py
+++ b/vulnfeeds/tools/debian/debian_converter/convert_debian.py
@@ -62,6 +62,8 @@
 DSA_OR_DLA_WITH_NO_EXT = re.compile(r'd[sl]a-\d+')
 
 NOT_AFFECTED_VERSION = '<not-affected>'
+UNFIXED_VERSION = '<unfixed>'
+END_OF_LIFE_VERSION = '<end-of-life>'
 
 # Prefix used to identify a new date line
 GIT_DATE_PREFIX = '-----'
@@ -90,7 +92,8 @@ def __init__(self, version: str, package: str, fixed: str):
     self.debian_release_version = version
 
   def to_dict(self):
-    return {
+    """Convert to dict for output"""
+    result = {
         'package': {
             'ecosystem': 'Debian:' + self.debian_release_version,
             'name': self.package
@@ -99,12 +102,15 @@ def to_dict(self):
             'type': 'ECOSYSTEM',
             'events': [{
                 'introduced': '0'
-            }, {
-                'fixed': self.fixed
             }]
         }],
     }
 
+    if self.fixed:
+      result['ranges'][0]['events'].append({'fixed': self.fixed})
+
+    return result
+
   def __repr__(self):
     return json.dumps(self, default=dumper)
 
@@ -214,7 +220,14 @@ def parse_security_tracker_file(advisories: Advisories,
         release_name = version_match.group(1)
         package_name = version_match.group(2)
         fixed_ver = version_match.group(3)
+
+        # Only create advisory if the version is affected.
         if fixed_ver != NOT_AFFECTED_VERSION:
+          # If fixed version is one of the following special values
+          # fixed version essentially doesn't exist, so blank it
+          if fixed_ver in [UNFIXED_VERSION, END_OF_LIFE_VERSION]:
+            fixed_ver = ''
+
           advisories[current_advisory].affected.append(
               AffectedInfo(codename_to_version[release_name], package_name,
                            fixed_ver))


Test patch:
Repository: google/osv.dev

Issue:
osv.dev  search by Repo URL
**Is your feature request related to a problem? Please describe.**
It's confusing / frustrating that you can't search by repo URL, especially for ecosystemless adivisories, which the only way to identify the package, is by repo URL. It also shows up under Packages in the vulnerability list, so allowing search keeps it consistent.

![image](https://github.com/google/osv.dev/assets/106129829/64e849f7-8711-4f7c-bf75-cb37dd1542da)


**Describe the solution you'd like**
Search indices should be also populated by repo URL (with and without scheme, and maybe each segment in the repo URL?). 

E.g. for repourl `https://github.com/MariaDB/server`
search_indicies should also have `https://github.com/MariaDB/server`, `github.com/MariaDB/server`, `MariaDB`, `server`





Discussion:
Hi @another-rex ! 👋
I can fix this issue, can you please assign me?
@aidoskanapyanov this one may be challenging to work on without an instance of OSV.dev running on GCP, so it may not be the best first issue for an external contributor. Feel free to sample the others, or if you want to try and spin up an instance of OSV.dev on your own GCP project, that would be a good test of the ability for an external contributor to do so...

Resolving patch:
diff --git a/osv/models.py b/osv/models.py
--- a/osv/models.py
+++ b/osv/models.py
@@ -402,6 +402,15 @@ def _pre_put_hook(self):  # pylint: disable=arguments-differ
     for alias in self.aliases:
       search_indices.update(self._tokenize(alias))
 
+    for affected_package in self.affected_packages:
+      for affected_range in affected_package.ranges:
+        if affected_range.repo_url and affected_range.repo_url != '':
+          url_no_https = affected_range.repo_url.split('//')[1]  # remove https
+          repo_url_indices = url_no_https.split('/')[1:]  # remove domain
+          repo_url_indices.append(affected_range.repo_url)  # add full url
+          repo_url_indices.append(url_no_https)  # add url without https://
+          search_indices.update(repo_url_indices)
+
     self.search_indices = list(set(search_indices))
     self.search_indices.sort()
 


Test patch:
Repository: google/osv.dev

Issue:
Disable automatic OSS-Fuzz -> OSV import for BoringSSL
In principle, this import is great and we'd love to have it. However, until the following issues are resolved, the tradeoffs are not viable. I would much *much* rather we lose the OSV import than lose the fuzzers, so please disable the import.
* https://github.com/google/oss-fuzz/issues/11925
* https://github.com/google/oss-fuzz/issues/11939
* https://github.com/google/osv.dev/issues/2176
* https://github.com/google/osv.dev/issues/2177


Discussion:

Resolving patch:
diff --git a/docker/worker/oss_fuzz.py b/docker/worker/oss_fuzz.py
--- a/docker/worker/oss_fuzz.py
+++ b/docker/worker/oss_fuzz.py
@@ -39,6 +39,7 @@
 # Large projects which take way too long to build.
 # TODO(ochang): Don't hardcode this.
 PROJECT_DENYLIST = {
+    'boringssl',  # https://github.com/google/osv.dev/issues/2178
     'ffmpeg',
     'imagemagick',
     'libreoffice',
diff --git a/docker/worker/worker.py b/docker/worker/worker.py
--- a/docker/worker/worker.py
+++ b/docker/worker/worker.py
@@ -48,18 +48,6 @@
 MAX_LEASE_DURATION = 6 * 60 * 60  # 4 hours.
 _TIMEOUT_SECONDS = 60
 
-# Large projects which take way too long to build.
-# TODO(ochang): Don't hardcode this.
-PROJECT_DENYLIST = {
-    'ffmpeg',
-    'imagemagick',
-    'libreoffice',
-}
-
-REPO_DENYLIST = {
-    'https://github.com/google/AFL.git',
-}
-
 _ECOSYSTEM_PUSH_TOPICS = {
     'PyPI': 'pypi-bridge',
 }


Test patch:
Repository: pytorch/vision

Issue:
[Feature Request] Add RandomVerticalFlip transform
Should be easy - I'll get to it in the next week if nobody else does. 


Discussion:

Resolving patch:
diff --git a/torchvision/transforms.py b/torchvision/transforms.py
--- a/torchvision/transforms.py
+++ b/torchvision/transforms.py
@@ -338,6 +338,22 @@ def __call__(self, img):
         return img
 
 
+class RandomVerticalFlip(object):
+    """Vertically flip the given PIL.Image randomly with a probability of 0.5"""
+
+    def __call__(self, img):
+        """
+        Args:
+            img (PIL.Image): Image to be flipped.
+
+        Returns:
+            PIL.Image: Randomly flipped image.
+        """
+        if random.random() < 0.5:
+            return img.transpose(Image.FLIP_TOP_BOTTOM)
+        return img
+
+
 class RandomSizedCrop(object):
     """Crop the given PIL.Image to random size and aspect ratio.
 


Test patch:
diff --git a/test/test_transforms.py b/test/test_transforms.py
--- a/test/test_transforms.py
+++ b/test/test_transforms.py
@@ -9,6 +9,11 @@
 except ImportError:
     accimage = None
 
+try:
+    from scipy import stats
+except ImportError:
+    stats = None
+
 
 GRACE_HOPPER = 'assets/grace_hopper_517x606.jpg'
 
@@ -327,6 +332,34 @@ def test_ndarray_gray_int32_to_pil_image(self):
         assert img.mode == 'I'
         assert np.allclose(img, img_data[:, :, 0])
 
+    @unittest.skipIf(stats is None, 'scipy.stats not available')
+    def test_random_vertical_flip(self):
+        img = transforms.ToPILImage()(torch.rand(3, 10, 10))
+        vimg = img.transpose(Image.FLIP_TOP_BOTTOM)
+
+        num_vertical = 0
+        for _ in range(100):
+            out = transforms.RandomVerticalFlip()(img)
+            if out == vimg:
+                num_vertical += 1
+
+        p_value = stats.binom_test(num_vertical, 100, p=0.5)
+        assert p_value > 0.05
+
+    @unittest.skipIf(stats is None, 'scipy.stats not available')
+    def test_random_horizontal_flip(self):
+        img = transforms.ToPILImage()(torch.rand(3, 10, 10))
+        himg = img.transpose(Image.FLIP_LEFT_RIGHT)
+
+        num_horizontal = 0
+        for _ in range(100):
+            out = transforms.RandomHorizontalFlip()(img)
+            if out == himg:
+                num_horizontal += 1
+
+        p_value = stats.binom_test(num_horizontal, 100, p=0.5)
+        assert p_value > 0.05
+
 
 if __name__ == '__main__':
     unittest.main()
Repository: pytorch/vision

Issue:
Phototour dataset links are broken.
Hi there,
I was trying triplet code on the this fork https://github.com/edgarriba/examples
But dataset link are broken? @edgarriba can you prvoide updated links?

thanks,
Aytac


Discussion:
Hi @aytackanaci,

The dataset is hosted as `iis.ee.ic.ac.uk` under @vbalnt's homepage. Currently `iis.ee.ic.ac.uk` seems to be down, hence the data cannot be pulled. I assume this will be fixed shortly, if not I think we can pull the data from [here](http://phototour.cs.washington.edu/patches/default.htm) instead.
Website is still down, let's wait until mid-week to see if they resolve it. The site `ic.ac.uk` is down so I'm sure someone there will see this soon.
@aytackanaci @alykhantejani let me ping them directly 
@edgarriba @aytackanaci I checked with Vassileios (@vbalnt) yesterday. He is in the process of migrating the data of the IC servers (as they are down).  Once he has uploaded them somewhere else, we will change the links in the dataset. 
Hi @alykhantejani  @edgarriba @aytackanaci 

Sorry for this, some servers at Imperial College had issues. Please find the new links below

```
http://icvl.ee.ic.ac.uk/vbalnt/liberty.zip
http://icvl.ee.ic.ac.uk/vbalnt/notredame.zip
http://icvl.ee.ic.ac.uk/vbalnt/yosemite.zip
```
Thanks @vbalnt - I'll update the links in the dataset now

Resolving patch:
diff --git a/torchvision/datasets/phototour.py b/torchvision/datasets/phototour.py
--- a/torchvision/datasets/phototour.py
+++ b/torchvision/datasets/phototour.py
@@ -25,17 +25,17 @@ class PhotoTour(data.Dataset):
     """
     urls = {
         'notredame': [
-            'http://www.iis.ee.ic.ac.uk/~vbalnt/phototourism-patches/notredame.zip',
+            'http://icvl.ee.ic.ac.uk/vbalnt/notredame.zip',
             'notredame.zip',
             '509eda8535847b8c0a90bbb210c83484'
         ],
         'yosemite': [
-            'http://www.iis.ee.ic.ac.uk/~vbalnt/phototourism-patches/yosemite.zip',
+            'http://icvl.ee.ic.ac.uk/vbalnt/yosemite.zip',
             'yosemite.zip',
             '533b2e8eb7ede31be40abc317b2fd4f0'
         ],
         'liberty': [
-            'http://www.iis.ee.ic.ac.uk/~vbalnt/phototourism-patches/liberty.zip',
+            'http://icvl.ee.ic.ac.uk/vbalnt/liberty.zip',
             'liberty.zip',
             'fdd9152f138ea5ef2091746689176414'
         ],


Test patch:
Repository: pytorch/vision

Issue:
utils.save_image fails when passing list of images
utils.save_image fails when passing in a list of images, as the code tries to call .cpu on the list. 
Passing in a list should be possible according to the function's documentation.


Discussion:
@mseitzer thanks - this looks like a bug. Can you send a PR? If not I will try and get to it at some point this week
@alykhantejani Facing the same issue. Can send a PR if you are still not on it.
@yannadani thanks, that would be great!

Resolving patch:
diff --git a/torchvision/utils.py b/torchvision/utils.py
--- a/torchvision/utils.py
+++ b/torchvision/utils.py
@@ -93,9 +93,8 @@ def save_image(tensor, filename, nrow=8, padding=2,
         **kwargs: Other arguments are documented in ``make_grid``.
     """
     from PIL import Image
-    tensor = tensor.cpu()
     grid = make_grid(tensor, nrow=nrow, padding=padding, pad_value=pad_value,
                      normalize=normalize, range=range, scale_each=scale_each)
-    ndarr = grid.mul(255).clamp(0, 255).byte().permute(1, 2, 0).numpy()
+    ndarr = grid.mul(255).clamp(0, 255).byte().permute(1, 2, 0).cpu().numpy()
     im = Image.fromarray(ndarr)
     im.save(filename)


Test patch:
Repository: pytorch/vision

Issue:
Error closing: 'NoneType' object has no attribute 'close' for ImageNet reading
When loading ImageNet, I get the following debug messages
`Error closing: 'NoneType' object has no attribute 'close' for ImageNet reading`
message called from https://github.com/pytorch/vision/blob/45dab0e4528333332f07ab1979e006857563cf99/torchvision/datasets/folder.py#L46

caused by
https://github.com/python-pillow/Pillow/blob/7d8c0d9e39d5ed79ea6aa590b9cbff5b0d17248c/PIL/Image.py#L573


Discussion:
This would suggest the `img` is `None`. Are you sure you are setting the `root` and `transform` correctly in the `ImageFolder` constructor?  Could you pose a minimum working example?
@alykhantejani The network works fine, and img seems to be assigned None after usage or something. An (not that minimal) example is that code: https://github.com/eladhoffer/convNet.pytorch running on ImageNet 
@Randl does this issue happen on a specific image/specific images? It might be a corrupt image in your download
@alykhantejani it looks like it happens for every single image
@Randl hmm that's very strange indeed. Does this also happen with the MNIST example? (Just trying to find a MWE that I can run over here). 

Let me know about MNIST, I'll take a look at this tomorrow and try and reproduce on my end - thanks for reporting!
@Randl did you find a solution for this?

Resolving patch:
diff --git a/torchvision/datasets/folder.py b/torchvision/datasets/folder.py
--- a/torchvision/datasets/folder.py
+++ b/torchvision/datasets/folder.py
@@ -48,8 +48,8 @@ def make_dataset(dir, class_to_idx):
 def pil_loader(path):
     # open path as file to avoid ResourceWarning (https://github.com/python-pillow/Pillow/issues/835)
     with open(path, 'rb') as f:
-        with Image.open(f) as img:
-            return img.convert('RGB')
+        img = Image.open(f)
+        return img.convert('RGB')
 
 
 def accimage_loader(path):


Test patch:
Repository: pytorch/vision

Issue:
utils.make_grid should not return tensors of dimension 2 or 3 without normalizing them
When passing in a single image of dimensionality 2 or 3 to utils.make_grid, the function currently returns this image, without normalizing it (but it should, according to the function's documentation).
This is also problematic as utils.save_image calls utils.make_grid to normalize its images. 


Discussion:
Hi @mseitzer,

The d[ocs for make grid ](http://pytorch.org/docs/master/torchvision/utils.html#torchvision.utils.make_grid)and save image both specify `Normalize=False` by default. You can change this by passing `Normalize=True` to the function.
Hi @alykhantejani,

what I tried to say is that even when passing `normalize=True`, tensors of dimensionality 2 or 3 are not normalized. This is due to an early return, see https://github.com/pytorch/vision/blob/c9b8914528f70fc8444a913a0934a0e44bff67c1/torchvision/utils.py#L37-L42

I would consider this a bug.

Ah ok, yes this looks like a bug. I'll try and fix this and the other utils one this week. Thanks for reporting!

Resolving patch:
diff --git a/torchvision/utils.py b/torchvision/utils.py
--- a/torchvision/utils.py
+++ b/torchvision/utils.py
@@ -39,7 +39,8 @@ def make_grid(tensor, nrow=8, padding=2,
     if tensor.dim() == 3:  # single image
         if tensor.size(0) == 1:  # if single-channel, convert to 3-channel
             tensor = torch.cat((tensor, tensor, tensor), 0)
-        return tensor
+        tensor = tensor.view(1, tensor.size(0), tensor.size(1), tensor.size(2))
+
     if tensor.dim() == 4 and tensor.size(1) == 1:  # single-channel images
         tensor = torch.cat((tensor, tensor, tensor), 1)
 
@@ -65,6 +66,9 @@ def norm_range(t, range):
         else:
             norm_range(tensor, range)
 
+    if tensor.size(0) == 1:
+        return tensor.squeeze()
+
     # make the mini-batch of images into a grid
     nmaps = tensor.size(0)
     xmaps = min(nrow, nmaps)


Test patch:
Repository: pytorch/vision

Issue:
Normalize() transform has undocumented side effect
It seems like [F.normalize()](https://github.com/pytorch/vision/blob/master/torchvision/transforms/functional.py#L168) does all of its operations in-place. 

I feel like this should either be very clearly documented or be hidden behind a flag.

This really bit me when I was just sending some batch images to Visdom but my denormalization function was silently denormalizing my batch before doing a forward pass on the network. It was hidden to me until now and surfaces because a copy disappeared when I removed all Variable() wrappers.


Discussion:

Resolving patch:
diff --git a/torchvision/transforms/functional.py b/torchvision/transforms/functional.py
--- a/torchvision/transforms/functional.py
+++ b/torchvision/transforms/functional.py
@@ -151,6 +151,9 @@ def to_pil_image(pic, mode=None):
 def normalize(tensor, mean, std):
     """Normalize a tensor image with mean and standard deviation.
 
+    .. note::
+        This transform acts in-place, i.e., it mutates the input tensor.
+
     See :class:`~torchvision.transforms.Normalize` for more details.
 
     Args:
diff --git a/torchvision/transforms/transforms.py b/torchvision/transforms/transforms.py
--- a/torchvision/transforms/transforms.py
+++ b/torchvision/transforms/transforms.py
@@ -123,6 +123,9 @@ class Normalize(object):
     will normalize each channel of the input ``torch.*Tensor`` i.e.
     ``input[channel] = (input[channel] - mean[channel]) / std[channel]``
 
+    .. note::
+        This transform acts in-place, i.e., it mutates the input tensor.
+
     Args:
         mean (sequence): Sequence of means for each channel.
         std (sequence): Sequence of standard deviations for each channel.


Test patch:
Repository: pytorch/vision

Issue:
Dead link in ToPILImage
 - master branch

See the code
https://github.com/pytorch/vision/blob/50b2f910490a731c4cd50db5813b291860f02237/torchvision/transforms/transforms.py#L96

http://pillow.readthedocs.io/en/3.4.x/handbook/concepts.html#modes
is not a valid address any longer.


Discussion:

Resolving patch:
diff --git a/torchvision/transforms/transforms.py b/torchvision/transforms/transforms.py
--- a/torchvision/transforms/transforms.py
+++ b/torchvision/transforms/transforms.py
@@ -93,7 +93,7 @@ class ToPILImage(object):
             3. If the input has 1 channel, the ``mode`` is determined by the data type (i,e,
             ``int``, ``float``, ``short``).
 
-    .. _PIL.Image mode: http://pillow.readthedocs.io/en/3.4.x/handbook/concepts.html#modes
+    .. _PIL.Image mode: https://pillow.readthedocs.io/en/latest/handbook/concepts.html#concept-modes
     """
     def __init__(self, mode=None):
         self.mode = mode


Test patch:
Repository: pytorch/vision

Issue:
[docs] transforms.ToTensor() doesn't rescale pixels of floating-point images
I noticed that ToTensor() only rescales  pixels of integer-valued images. 
If `PIL.mode` corresponds to the image with the floating-point representation - no scaling to pixel values will be applied.

I think this should be documented in https://pytorch.org/docs/stable/torchvision/transforms.html?highlight=totensor#torchvision.transforms.ToTensor. Otherwise it's too confusing.

Related to: https://github.com/pytorch/vision/issues/546


Discussion:
Yes, it should definitely be documented.
As I've mentioned in #546, I think we should do something to mitigate this inconsistency.

Could you send a PR improving the documentation?
Yes, sure. I will send a PR.

Resolving patch:
diff --git a/torchvision/transforms/functional.py b/torchvision/transforms/functional.py
--- a/torchvision/transforms/functional.py
+++ b/torchvision/transforms/functional.py
@@ -77,7 +77,7 @@ def to_tensor(pic):
         img = 255 * torch.from_numpy(np.array(pic, np.uint8, copy=False))
     else:
         img = torch.ByteTensor(torch.ByteStorage.from_buffer(pic.tobytes()))
-    # PIL image mode: L, P, I, F, RGB, YCbCr, RGBA, CMYK
+    # PIL image mode: L, LA, P, I, F, RGB, YCbCr, RGBA, CMYK
     if pic.mode == 'YCbCr':
         nchannel = 3
     elif pic.mode == 'I;16':
diff --git a/torchvision/transforms/transforms.py b/torchvision/transforms/transforms.py
--- a/torchvision/transforms/transforms.py
+++ b/torchvision/transforms/transforms.py
@@ -73,7 +73,11 @@ class ToTensor(object):
     """Convert a ``PIL Image`` or ``numpy.ndarray`` to tensor.
 
     Converts a PIL Image or numpy.ndarray (H x W x C) in the range
-    [0, 255] to a torch.FloatTensor of shape (C x H x W) in the range [0.0, 1.0].
+    [0, 255] to a torch.FloatTensor of shape (C x H x W) in the range [0.0, 1.0]
+    if the PIL Image belongs to one of the modes (L, LA, P, I, F, RGB, YCbCr, RGBA, CMYK, 1)
+    or if the numpy.ndarray has dtype = np.uint8
+
+    In the other cases, tensors are returned without scaling.
     """
 
     def __call__(self, pic):


Test patch:
Repository: pytorch/vision

Issue:
to_pil_image mutates a 2-d tensor
@fmassa  is this intended ?
I feel this might create a problem if we have a batch of images as 2d tensor and we just want to generate the images by keeping the tensor as it is.

The Problem is here :

 https://github.com/pytorch/vision/blob/22bc44ed76ec314e8c27df1575757d82f2eda0a3/torchvision/transforms/functional.py#L120

Proposed Fix:
Adding inplace option in the args.


Discussion:
@surgan12 this mutation in particular is not expected I'd say. But note that in some cases we might share the storage of the tensor with the PIL image, which could potentially lead to mutation in the original tensor.
Can you just send a PR doing
```python
pic = pic.unsqueeze(0)
```
?
@fmassa  sure !!

Resolving patch:
diff --git a/torchvision/transforms/functional.py b/torchvision/transforms/functional.py
--- a/torchvision/transforms/functional.py
+++ b/torchvision/transforms/functional.py
@@ -117,7 +117,7 @@ def to_pil_image(pic, mode=None):
 
         elif pic.ndimension() == 2:
             # if 2D image, add channel dimension (CHW)
-            pic.unsqueeze_(0)
+            pic = pic.unsqueeze(0)
 
     elif isinstance(pic, np.ndarray):
         if pic.ndim not in {2, 3}:


Test patch:
Repository: pytorch/vision

Issue:
`UserWarning` when applying `Normalize`
Hi!
pytorch's version: 1.0.1.post2
torchvision's version: 0.2.2.post3

Sorry for the formatting, but you need to scroll the snippet to the right in order to see the warning.

```python
>>> from torch import tensor
>>> from torchvision.transforms import Normalize
>>> n = Normalize(tensor([1.0, 2.0, 3.0]),  tensor([1.0, 2.0, 3.0]))
>>> t = tensor([1.0, 2.0, 3.0]).view(3, 1, 1)
>>> n(t)
/home/ygorishniy/miniconda3/envs/x/lib/python3.6/site-packages/torchvision/transforms/functional.py:206: UserWarning: To copy construct from a tensor, it is recommended to use sourceTensor.clone().detach() or sourceTensor.clone().detach().requires_grad_(True), rather than torch.tensor(sourceTensor).
  mean = torch.tensor(mean, dtype=torch.float32)
/home/ygorishniy/miniconda3/envs/x/lib/python3.6/site-packages/torchvision/transforms/functional.py:207: UserWarning: To copy construct from a tensor, it is recommended to use sourceTensor.clone().detach() or sourceTensor.clone().detach().requires_grad_(True), rather than torch.tensor(sourceTensor).
  std = torch.tensor(std, dtype=torch.float32)
Out[17]: 
tensor([[[0.]],
             [[0.]],
             [[0.]]])
```


Discussion:

Resolving patch:
diff --git a/torchvision/transforms/functional.py b/torchvision/transforms/functional.py
--- a/torchvision/transforms/functional.py
+++ b/torchvision/transforms/functional.py
@@ -203,8 +203,8 @@ def normalize(tensor, mean, std, inplace=False):
     if not inplace:
         tensor = tensor.clone()
 
-    mean = torch.tensor(mean, dtype=torch.float32, device=tensor.device)
-    std = torch.tensor(std, dtype=torch.float32, device=tensor.device)
+    mean = torch.as_tensor(mean, dtype=torch.float32, device=tensor.device)
+    std = torch.as_tensor(std, dtype=torch.float32, device=tensor.device)
     tensor.sub_(mean[:, None, None]).div_(std[:, None, None])
     return tensor
 


Test patch: