Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@val-shkolnikov

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

This PR is stale because it has been open for 30 days with no activity.

Could you change the title for conformance: 'bpo' also the PR number? Also, please check why checks are failing, e.g. why no news?

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@iritkatriel How do we check if the CLA has been signed?

@iritkatriel How do we check if the CLA has been signed?

that should be automated.

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

The following commit authors need to sign the Contributor License Agreement:

• val.shkolnikov@broadcom.net

Click the button to sign:

The following commit authors need to sign the Contributor License Agreement:

* [val.shkolnikov@broadcom.net](mailto:val.shkolnikov@broadcom.net)

This is an incorrect email. My email is val@nvsoft.net. I signed the CLA with that email.

The following commit authors need to sign the Contributor License Agreement:

* [val.shkolnikov@broadcom.net](mailto:val.shkolnikov@broadcom.net)

This is an incorrect email. My email is val@nvsoft.net. I signed the CLA with that email.

The bot picked up this email from somewhere. I can think of two easy solutions - sign the CLA again with that email, or close this PR and create a new one with the email you used to sign the CLA.

Please add a unit test covering this change.

The tests for the tar file module are at https://github.com/python/cpython/blob/main/Lib/test/test_tarfile.py

Please add a unit test covering this change.

The tests for the tar file module are at https://github.com/python/cpython/blob/main/Lib/test/test_tarfile.py

I modified the related test. The patch is attached.
test_patch.txt

The following commit authors need to sign the Contributor License Agreement:

* [val.shkolnikov@broadcom.net](mailto:val.shkolnikov@broadcom.net)

This is an incorrect email. My email is val@nvsoft.net. I signed the CLA with that email.

The bot picked up this email from somewhere. I can think of two easy solutions - sign the CLA again with that email, or close this PR and create a new one with the email you used to sign the CLA.

If I close the PR and start a new one, do I need to re-submit all the material from scratch?

Please add a unit test covering this change.

The tests for the tar file module are at https://github.com/python/cpython/blob/main/Lib/test/test_tarfile.py

We don't accept patches as attachments anymore. You need to include it in the PR.

Please add a unit test covering this change.

The tests for the tar file module are at https://github.com/python/cpython/blob/main/Lib/test/test_tarfile.py

We don't accept patches as attachments anymore. You need to include it in the PR.

--- a/test_tarfile.py   2022-11-27 15:49:38.038411000 -0800
+++ b/test_tarfile.py   2022-11-27 15:49:49.286715000 -0800
@@ -302,11 +302,23 @@ class ListTest(ReadTest, unittest.TestCa
         # accessories if verbose flag is being used
         # ...
         # ?rw-r--r-- tarfile/tarfile     7011 2003-01-06 07:19:43 ustar/conttype
-        # ?rw-r--r-- tarfile/tarfile     7011 2003-01-06 07:19:43 ustar/regtype
+        # -rw-r--r-- tarfile/tarfile     7011 2003-01-06 07:19:43 ustar/regtype
+        # drwxr-xr-x tarfile/tarfile        0 2003-01-05 15:19:43 ustar/dirtype/
         # ...
-        self.assertRegex(out, (br'\?rw-r--r-- tarfile/tarfile\s+7011 '
-                               br'\d{4}-\d\d-\d\d\s+\d\d:\d\d:\d\d '
-                               br'ustar/\w+type ?\r?\n') * 2)
+        #
+        # Array of values to modify the regex below:
+        #  ((file_type, file_permissions, file_length), ...)
+        type_perm_lengths = (
+            (r'\?', 'rw-r--r--', '7011'), ('-', 'rw-r--r--', '7011'),
+            ('d', 'rwxr-xr-x', '0'), ('d', 'rwxr-xr-x', '255'),
+            (r'\?', 'rw-r--r--', '0'), ('l', 'rwxrwxrwx', '0'),
+            ('b', 'rw-rw----', '3,0'), ('c', 'rw-rw-rw-', '1,3'),
+            ('p', 'rw-r--r--', '0'))
+        self.assertRegex(out.decode(), ''.join(
+            [(tp + (r'%s tarfile/tarfile\s+%s ' % (perm, ln) +
+                    r'\d{4}-\d\d-\d\d\s+\d\d:\d\d:\d\d '
+                    r'ustar/\w+type[/>\sa-z-]*\n')) for tp, perm, ln
+                    in type_perm_lengths]))
         # Make sure it prints the source of link with verbose flag
         self.assertIn(b'ustar/symtype -> regtype', out)
         self.assertIn(b'./ustar/linktest2/symtype -> ../linktest1/regtype', out)

Please go over the ‘collaborative coding’ section of the GitHub documentation to see how it works: https://docs.github.com/en

Issue numbers on PRs need to be disambiguated with a bpo- or gh- prefix. The initial issue# was a bpo number. I replaced it, with a prefix, with the new github issue number.

Because there are usually over 100 blurbs per release, we try to limit them to a line or two. Details, like the example, belong on the issue.

The test revision needs to be added to the PR by switching to your tarfile-fix branch, editing test_tarfile, saving it, and running the test suite locally to test that the test runs on your machine without breaking anything. If it passes, commit it and push the new commit to your fork, as you did to make the PR. The new commit should show up here. This should not affect my revision of the blurb. Do this a few times and revising PRs will become routine.

@val-shkolnikov : the CLA is still an issue. I would suggest just signing it again with the email address tied to the account you are using for PRs.

@val-shkolnikov : the CLA is still an issue. I would suggest just signing it again with the email address tied to the account you are using for PRs.

Unfortunately I cannot do that. This patch dates way back. Broadcom changed their email to go to broadcom.com instead of broadcom.net, so this email address is not valid anymore.

If I create a new PR, is there a way to reference this PR in there or have some method to make sure that the new PR gets reviewed by the same people?

When you create the new PR, post a comment here with the number, then anyone following can click through to it.

Automated systems failed us on this one. See above PR for current attempt.