internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: aws/aws-cli

Issue:
EKS update-config not working when updating cluster
I am not sure if by design. In case it isnt, executing:

```
aws eks update-kubeconfig --name dev-tools --kubeconfig ~/.kube/dev-tools
```

Yields into following the error message:
```
Cluster status not active
```
When the cluster is updating: `"status": "UPDATING",`.


**Steps:**
1. create cluster with older version
2. update-cluster to newer version
3. execute `aws eks update-kubeconfig`
4. error

------
After looking into the source code it looks like this is because it only checks for the status "Active". Everything else is not allowed.


Discussion:
https://github.com/aws/aws-cli/blob/bbeb9a1bc72982b00d974bf35424f6f3bce26e63/awscli/customizations/eks/update_kubeconfig.py#L290

Here the line of code causing this.
@ktugan - Thank you for reaching out.  Just so I understand your ask here.  Are you looking for us to add a feature to improve the error messages? 
I should have stated my intentions clearer. From what I see there is two options to go forward:

1. kubectl works normal and as intended when the cluster is in `UPDATING`
-> I would change the code as following:
```
if self._cluster_description["status"] != "ACTIVE":  # current
-->
if self._cluster_description["status"] not in ["ACTIVE", "UPDATING"]:  # suggested
```

2. kubectl doesn't work properly while the cluster is updating: keep it as it is

Hope that makes it clearer. Sorry for not taking the time to writing it properly the first time.
@ktugan - Thank you for your feedback and for pointing this out.  I'm labeling this as a feature request and confusing error pending further review.  

Resolving patch:
diff --git a/awscli/customizations/eks/update_kubeconfig.py b/awscli/customizations/eks/update_kubeconfig.py
--- a/awscli/customizations/eks/update_kubeconfig.py
+++ b/awscli/customizations/eks/update_kubeconfig.py
@@ -258,8 +258,10 @@ def _get_cluster_description(self):
 
             if "status" not in self._cluster_description:
                 raise EKSClusterError("Cluster not found")
-            if self._cluster_description["status"] != "ACTIVE":
-                raise EKSClusterError("Cluster status not active")
+            if self._cluster_description["status"] not in ["ACTIVE", "UPDATING"]:
+                raise EKSClusterError("Cluster status is {0}".format(
+                    self._cluster_description["status"]
+                ))
 
         return self._cluster_description
 


Test patch:
Repository: aws/aws-cli

Issue:
aws cloudformation prints S3 upload progress to STDOUT
When running `aws cloudformation package`, the output must not include the S3 upload progress.

It currently includes the combined output of the S3 file upload as well as packaged CloudFormation itself making it impossible to use via STDOUT.

See the full repro at https://github.com/dnagir/cf-package-stdout-messed-up

Workaround - use `--output-template-file` option.


Discussion:
@sanathkr thoughts?
Agreed. Progress should print to stderr. Care to submit a PR? Should be a quick one. 

I don’t consider this a breaking change because the progress bar was not something someone would take a dependency on. 

Resolving patch:
diff --git a/awscli/customizations/s3uploader.py b/awscli/customizations/s3uploader.py
--- a/awscli/customizations/s3uploader.py
+++ b/awscli/customizations/s3uploader.py
@@ -220,8 +220,8 @@ def on_progress(self, future, bytes_transferred, **kwargs):
         with self._lock:
             self._seen_so_far += bytes_transferred
             percentage = (self._seen_so_far / self._size) * 100
-            sys.stdout.write(
+            sys.stderr.write(
                     "\rUploading to %s  %s / %s  (%.2f%%)" %
                     (self._remote_path, self._seen_so_far,
                      self._size, percentage))
-            sys.stdout.flush()
+            sys.stderr.flush()


Test patch:
Repository: aws/aws-cli

Issue:
aws emr create-cluster help command returns error
how to reproduce 

1. upgrade to awscli 1.16.190 or 1.16.194 or 1.16.196
at the moment it's enough to install via pip either on macOS(1.16.194) or on linux(1.16.196), or using Homebrew(1.16.190) on macOS
```
# on Ubuntu 16.04 linux 
$ pip install --upgrade awscli
<... output skipped - but it was successful, no errors ...>

$ aws --version
aws-cli/1.16.196 Python/2.7.12 Linux/4.4.0-97-generic botocore/1.12.186

$ aws emr create-cluster help

[Errno 2] No such file or directory: '/usr/local/lib/python2.7/dist-packages/awscli/examples/emr/create-cluster-synopsis.txt'



#or on macOS just for example using the one installed via Homebrew
$ brew install awscli
<... output skipped - but it was successful, no errors ...>

$ aws --version
aws-cli/1.16.190 Python/3.7.4 Darwin/18.6.0 botocore/1.12.180

$ aws emr create-cluster help
[Errno 2] No such file or directory: '/usr/local/Cellar/awscli/1.16.190/libexec/lib/python3.7/site-packages/awscli/examples/emr/create-cluster-synopsis.txt'

#or on macOS using aws installed via pip3
$ aws emr create-cluster help

[Errno 2] No such file or directory: '/usr/local/lib/python3.7/site-packages/awscli/examples/emr/create-cluster-synopsis.txt'
```


Discussion:
@VitSkakun - Thank you for reporting this issue.  I can confirm the behavior and will label it as such.  We are looking into getting this resolved.  Do you need any other guidance with the `aws emr create-cluster` command?
> Do you need any other guidance with the aws emr create-cluster command?

@justnance - it's ok, thank you for asking. I used  the docs on Amazon documentation website.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -54,6 +54,7 @@ def find_version(*file_paths):
              'bin/aws_bash_completer'],
     packages=find_packages(exclude=['tests*']),
     package_data={'awscli': ['data/*.json', 'examples/*/*.rst',
+                             'examples/*/*.txt', 'examples/*/*/*.txt',
                              'examples/*/*/*.rst', 'topics/*.rst',
                              'topics/*.json']},
     install_requires=requires,


Test patch:
diff --git a/tests/functional/docs/test_examples.py b/tests/functional/docs/test_examples.py
--- a/tests/functional/docs/test_examples.py
+++ b/tests/functional/docs/test_examples.py
@@ -258,3 +258,15 @@ def visit_literal_block(self, node):
 
     def default_visit(self, node):
         pass
+
+
+
+def test_only_rst_and_txt_example_files():
+    for root, _, files in os.walk(EXAMPLES_DIR):
+        for filename in files:
+            filepath = os.path.join(root, filename)
+            yield (_assert_file_is_rst_or_txt, filepath)
+
+
+def _assert_file_is_rst_or_txt(filepath):
+    assert filepath.endswith('.rst') or filepath.endswith('.txt')
Repository: aws/aws-cli

Issue:
Broken docutils==0.15
Hi community,

Today docutils were updated to 0.15 (https://pypi.org/project/docutils/#history) and it breaks awscli running on Python 2.

```
# aws --version
Traceback (most recent call last):
  File "/bin/aws", line 19, in <module>
    import awscli.clidriver
  File "/usr/lib/python2.7/site-packages/awscli/clidriver.py", line 36, in <module>
    from awscli.help import ProviderHelpCommand
  File "/usr/lib/python2.7/site-packages/awscli/help.py", line 20, in <module>
    from docutils.core import publish_string
  File "/usr/lib/python2.7/site-packages/docutils/core.py", line 246
    print('\n::: Runtime settings:', file=self._stderr)
                                         ^
SyntaxError: invalid syntax
```


Discussion:
Yes, workaround using 
`pip install docutils==0.14`
after the installation of the aws cli



> Yes, workaround using
> `pip install docutils==0.14`
> after the installation of the aws cli

yup using the same workaround
good one ;)
all the aws cli looks broken with last version of docutils yep ..

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -25,7 +25,7 @@ def find_version(*file_paths):
 
 requires = ['botocore==1.12.191',
             'colorama>=0.2.5,<=0.3.9',
-            'docutils>=0.10',
+            'docutils>=0.10,<0.15',
             'rsa>=3.1.2,<=3.5.0',
             's3transfer>=0.2.0,<0.3.0']
 


Test patch:
Repository: aws/aws-cli

Issue:
A collection of new MediaStore CLI examples

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.



Discussion:

Resolving patch:
diff --git a/awscli/customizations/cloudformation/artifact_exporter.py b/awscli/customizations/cloudformation/artifact_exporter.py
--- a/awscli/customizations/cloudformation/artifact_exporter.py
+++ b/awscli/customizations/cloudformation/artifact_exporter.py
@@ -438,6 +438,7 @@ def do_export(self, resource_id, resource_dict, parent_dir):
         template_path = resource_dict.get(self.PROPERTY_NAME, None)
 
         if template_path is None or is_s3_url(template_path) or \
+                template_path.startswith(self.uploader.s3.meta.endpoint_url) or \
                 template_path.startswith("https://s3.amazonaws.com/"):
             # Nothing to do
             return


Test patch:
diff --git a/tests/unit/customizations/cloudformation/test_artifact_exporter.py b/tests/unit/customizations/cloudformation/test_artifact_exporter.py
--- a/tests/unit/customizations/cloudformation/test_artifact_exporter.py
+++ b/tests/unit/customizations/cloudformation/test_artifact_exporter.py
@@ -210,6 +210,7 @@ class TestArtifactExporter(unittest.TestCase):
 
     def setUp(self):
         self.s3_uploader_mock = Mock()
+        self.s3_uploader_mock.s3.meta.endpoint_url = "https://s3.some-valid-region.amazonaws.com"
 
     def test_parse_s3_url(self):
 
@@ -746,6 +747,18 @@ def test_export_cloudformation_stack_no_upload_path_is_httpsurl(self):
         self.assertEquals(resource_dict[property_name], s3_url)
         self.s3_uploader_mock.upload_with_dedup.assert_not_called()
 
+    def test_export_cloudformation_stack_no_upload_path_is_s3_region_httpsurl(self):
+        stack_resource = CloudFormationStackResource(self.s3_uploader_mock)
+        resource_id = "id"
+        property_name = stack_resource.PROPERTY_NAME
+
+        s3_url = "https://s3.some-valid-region.amazonaws.com/hello/world"
+        resource_dict = {property_name: s3_url}
+
+        stack_resource.export(resource_id, resource_dict, "dir")
+        self.assertEquals(resource_dict[property_name], s3_url)
+        self.s3_uploader_mock.upload_with_dedup.assert_not_called()
+
     def test_export_cloudformation_stack_no_upload_path_is_empty(self):
         stack_resource = CloudFormationStackResource(self.s3_uploader_mock)
         resource_id = "id"
Repository: aws/aws-cli

Issue:
Service Catalog --support-url not being passed as String but does a HTTP get
Hi,

While utilizing the service catalog CLI if the parameter of --support-url is used for the create-product, the CLI does an actual HTTP get request on the URL provided instead of just giving the parameter as a string. Since the URL would return the entire HTTP response it would go over the limit of 2083 characters. 

Even if the quotations are escaped a new error is retrieved, the only workaround I have found is to either have all the parameter values within a JSON file or to just have the support URL parameter within the JSON file.

Looking into the documentation of the behavior which could be causing this is here:
https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters.html#cli-usage-parameters-file-remote

Stating that:
"
The AWS CLI also supports loading parameters from a file hosted on the internet with an http:// or https:// URL
"
therefore I believe that the support url parameter is not being validated by the create-product CLI command but rather by the underlying CLI behavior.


Discussion:

Resolving patch:
diff --git a/awscli/paramfile.py b/awscli/paramfile.py
--- a/awscli/paramfile.py
+++ b/awscli/paramfile.py
@@ -101,6 +101,9 @@
     'serverlessapplicationrepository.update-application.home-page-url',
     'serverlessapplicationrepository.update-application.readme-url',
 
+    'service-catalog.create-product.support-url',
+    'service-catalog.update-product.support-url',
+
     'sqs.add-permission.queue-url',
     'sqs.change-message-visibility.queue-url',
     'sqs.change-message-visibility-batch.queue-url',


Test patch:
Repository: aws/aws-cli

Issue:
upgrade to PyYAML 5.2
PyYAML 5.2 is out, with more security fixes.  aws-cli pins to an older version, preventing upgrades.  Please update the pin.


Discussion:
Changes between 5.1...5.2 are fairly minimal and tests are passing for me when upgrading to 5.2.  I'll go ahead and update our pin on pyyaml.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -45,7 +45,7 @@ def find_version(*file_paths):
     # Colorama removed support for EOL pythons.
     install_requires.append('colorama>=0.2.5,<=0.3.9')
 else:
-    install_requires.append('PyYAML>=3.10,<5.2')
+    install_requires.append('PyYAML>=3.10,<5.3')
     install_requires.append('colorama>=0.2.5,<0.4.2')
 
 


Test patch:
Repository: aws/aws-cli

Issue:
Add support for PyYAML 5.3
Closes: https://github.com/aws/aws-cli/issues/4828
Signed-off-by: Igor Raits <i.gnatenko.brain@gmail.com>

*Issue #, if available:*

*Description of changes:*


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -28,13 +28,14 @@ def find_version(*file_paths):
     'docutils>=0.10,<0.16',
     'rsa>=3.1.2,<=3.5.0',
     's3transfer>=0.3.0,<0.4.0',
-    'PyYAML>=3.10,<5.3',
 ]
 
 
 if sys.version_info[:2] == (3, 4):
+    install_requires.append('PyYAML>=3.10,<5.3')
     install_requires.append('colorama>=0.2.5,<0.4.2')
 else:
+    install_requires.append('PyYAML>=3.10,<5.4')
     install_requires.append('colorama>=0.2.5,<0.4.4')
 
 


Test patch:
Repository: aws/aws-cli

Issue:
S3 presign cli allow url generated more than 7 days (--expires-in greater than 604800)
Confirm by changing [ ] to [x] below to ensure that it's a bug:
- [x ] I've gone though the [User Guide](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) and the [API reference](https://docs.aws.amazon.com/cli/latest/reference/)
- [ x] I've searched for [previous similar issues](https://github.com/aws/aws-cli/issues) and didn't find any solution
  
**Describe the bug**
aws s3 presign --expires-in 604801 will allow url to be generated. But when view the url, S3 will said that url is not valid as it's expiring in more than 7 days. 

Error message: 
X-Amz-Expires must be less than a week (in seconds); that is, the given X-Amz-Expires must be less than 604800 seconds

**SDK version number**
aws --version
aws-cli/2.0.17 Python/3.7.4 Darwin/19.6.0 botocore/2.0.0dev21

**Platform/OS/Hardware/Device**
macOS Catalina 10.15.6

**To Reproduce (observed behavior)**
Run: aws s3 presign --expires-in 604801 s3://any-object

**Expected behavior**
When generate expires-in greater than 604800, it should reports error and not generate any url. 

**Logs/output**
N/A

**Additional context**
N/A



Discussion:
Looking into this, thanks!
Hi @kienpham2000, this maximum time limit is specific to S3 presigned URLs with the SigV4 signing method. Previously (SigV2) a presigned URL could be valid indefinitely. I'm going to mark this as a documentation issue to note the maximum value in the client documentation that is also present in the [S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/API/archive-sigv4-query-string-auth.html).
Thanks @kdaily , didn't know that :). 
Greetings! It looks like this issue hasn’t been active in longer than one year. We encourage you to check if this is still an issue in the latest release. Because it has been longer than one year since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment to prevent automatic closure, or if the issue is already closed, please feel free to reopen it.

Resolving patch:
diff --git a/awscli/customizations/s3/subcommands.py b/awscli/customizations/s3/subcommands.py
--- a/awscli/customizations/s3/subcommands.py
+++ b/awscli/customizations/s3/subcommands.py
@@ -687,7 +687,7 @@ class PresignCommand(S3Command):
                   'cli_type_name': 'integer',
                   'help_text': (
                       'Number of seconds until the pre-signed '
-                      'URL expires.  Default is 3600 seconds.')}]
+                      'URL expires.  Default is 3600 seconds. Maximum is 604800 seconds.')}]
 
     def _run_main(self, parsed_args, parsed_globals):
         super(PresignCommand, self)._run_main(parsed_args, parsed_globals)


Test patch:
Repository: aws/aws-cli

Issue:
Unknown interpreted text role "abc" while calling aws help config-vars
### Describe the bug

Error is shown instead of information how to configure variables.

### Expected Behavior

Display help how to configure variables.

### Current Behavior

```
<string>:450: (ERROR/3) Unknown interpreted text role "doc".
<string>:567: (SEVERE/4) Title level inconsistent:

==============
Global Options
==============

<string>:567: (SEVERE/4) Title level inconsistent:

==============
Global Options
==============
```

### Reproduction Steps

aws help config-vars

### Possible Solution

_No response_

### Additional Information/Context

_No response_

### CLI version used

aws-cli/2.8.2 Python/3.9.11 Windows/10 exe/AMD64 prompt/off

### Environment details (OS name and version, etc.)

Windows 11 Home 22H2 (compilation 22621.608)


Discussion:
Thanks @tlmikulski for bringing this to our attention. I believe this error was introduced in v2.7.26 when some updates were merged involving documentation commands. I think the problem relates to what is described [here](https://stackoverflow.com/questions/24504301/what-does-title-level-inconsistent-mean) involving some hierarchy/precedence rules. The team will need to look further into this.

Resolving patch:
diff --git a/awscli/clidocs.py b/awscli/clidocs.py
--- a/awscli/clidocs.py
+++ b/awscli/clidocs.py
@@ -655,6 +655,9 @@ def doc_options_start(self, help_command, **kwargs):
     def doc_options_end(self, help_command, **kwargs):
         pass
 
+    def doc_global_option(self, help_command, **kwargs):
+        pass
+
     def doc_subitems_start(self, help_command, **kwargs):
         doc = help_command.doc
         doc.style.h2('Available Topics')


Test patch:
diff --git a/tests/unit/test_clidocs.py b/tests/unit/test_clidocs.py
--- a/tests/unit/test_clidocs.py
+++ b/tests/unit/test_clidocs.py
@@ -652,6 +652,11 @@ def test_description_tags_in_body(self):
         contents = self.cmd.doc.getvalue().decode('utf-8')
         self.assertIn(ref_body, contents)
 
+    def test_excludes_global_options(self):
+        self.doc_handler.doc_global_option(self.cmd)
+        global_options = self.cmd.doc.getvalue().decode('utf-8')
+        self.assertNotIn('Global Options', global_options)
+
 
 class TestGlobalOptionsDocumenter(unittest.TestCase):
     def create_help_command(self):
Repository: comfyanonymous/ComfyUI

Issue:
Perp-Neg implementation is wrong, parallel component not ignored
https://github.com/comfyanonymous/ComfyUI/blob/18c151b3e3f6838fab4028e7a8ba526e30e610d3/comfy_extras/nodes_perpneg.py#L38-L40

The Perp-Neg node does not match the [paper](https://arxiv.org/pdf/2304.04968.pdf) (pytorch code in Appendix A.1).
When positive and negative prompt are the same, the result should be the same as an empty negative prompt because the prompts are completely parallel (i.e. there is no perpendicular component).

Positive: "forest"
Negative: ""
![ComfyUI_00194_](https://github.com/comfyanonymous/ComfyUI/assets/114889020/6c86c0d5-ec8b-478d-aa29-e41794bd3184)

Positive: "forest"
Negative: "forest"
![ComfyUI_00195_](https://github.com/comfyanonymous/ComfyUI/assets/114889020/fa4f2938-bc7a-48cb-8750-f76e6426dd4e)

I'll submit a PR in a bit.


Discussion:

Resolving patch:
diff --git a/comfy_extras/nodes_perpneg.py b/comfy_extras/nodes_perpneg.py
--- a/comfy_extras/nodes_perpneg.py
+++ b/comfy_extras/nodes_perpneg.py
@@ -35,7 +35,7 @@ def cfg_function(args):
 
             pos = noise_pred_pos - noise_pred_nocond
             neg = noise_pred_neg - noise_pred_nocond
-            perp = ((torch.mul(pos, neg).sum())/(torch.norm(neg)**2)) * neg
+            perp = neg - ((torch.mul(neg, pos).sum())/(torch.norm(pos)**2)) * pos
             perp_neg = perp * neg_scale
             cfg_result = noise_pred_nocond + cond_scale*(pos - perp_neg)
             cfg_result = x - cfg_result


Test patch:
Repository: sonic-net/sonic-mgmt

Issue:
SLB Test Cases

Step | Goal | Expected results
-- | -- | --
Create peering session from the SLB to Active ToR | SLB | Verify session is established
Create peering session from the SLB to Standby ToR | SLB | Verify session is established
  |   |  
Announce routes from SLB to Active ToR | SLB | Verify routes in Active ToR
Announce routes from SLB to Standby ToR | SLB | Verify routes in Standby ToR
  |   |  
Run PTF tests on Active ToR | SLB | Verify packets forwarded directly to active SLB port
Run PTF tests on Standby ToR | SLB | Verify packets forwarded via tunnel to Active ToR
  |   |  
Withdraw routes from SLB to Active ToR | SLB | Verify routes removed in Active ToR
Withdraw routes from SLB to Standby ToR | SLB | Verify routes removed in Standby ToR
  |   |  
Repeat PTF tests as above | SLB | Verify no packets forwarded
  |   |  
Simulate a mux state change for the SLB port | SLB | Verify both sessions stays established and not disrupted
  |   |  
Announce routes from SLB to new Active ToR | SLB | Verify routes in Active ToR
Announce routes from SLB to new Standby ToR | SLB | Verify routes in Standby ToR
  |   |  
Repeat PTF tests as above | SLB | Verify packet forwarding based on mux state
  |   |  
Verify teardown by shutting peering session one by one | SLB | After one session is down, verify other peering session is active and routes present




Discussion:

Resolving patch:
diff --git a/ansible/library/dual_tor_facts.py b/ansible/library/dual_tor_facts.py
--- a/ansible/library/dual_tor_facts.py
+++ b/ansible/library/dual_tor_facts.py
@@ -43,7 +43,7 @@ def parse_loopback_ips(self):
             loopback_ips[dut]['ipv4'] = self.vm_config['DUT']['loopback']['ipv4'][dut_num]
             loopback_ips[dut]['ipv6'] = self.vm_config['DUT']['loopback']['ipv6'][dut_num] 
 
-            for loopback_num in range(1, 3): # Generate two additional loopback IPs, Loopback1 and Loopback2
+            for loopback_num in range(1, 4): # Generate two additional loopback IPs, Loopback1, Loopback2, and Loopback3
                 loopback_key = 'loopback{}'.format(loopback_num)
                 loopback_dict = {}
                 loopback_dict['ipv4'] = self.vm_config['DUT'][loopback_key]['ipv4'][dut_num]


Test patch: