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

Issue:
Unreproducible build: base_library.zip contains references to source files
## Description of the issue

.pyc files in base_library.zip contain references to their source files. This is similar to #5377. 

## Context information (for bug reports)

* Output of `pyinstaller --version`: ```4.2```, ```5.0.dev0```
* Version of Python: 3.8.1
* Platform: Win10 En
* Did you also try this on another platform? Does it work there?
Did not try on another platform


## What I did:

1. Install Python 3.8.2 in 2 locations (e.g. C:\Python38 and C:\Python\Py38)
2. Create a virtual environment from one ```C:\Python38\python.exe -m venv .venv```
3. Create an empty test.py file ```touch test.py```
4. activate `.venv`
5. ```SET PYTHONHASHSEED=1```
6. invoke ```pyinstaller --clean -y test.py```
7. copy the output to another location
8. repeat steps 2-6 with the other install
9. compare base library of the 2 builds and observe the differences in the .pyc files

## More:

The root cause seems to be that the mod.code is not having strip_paths_in_code invoked on it prior to writing it like is done in other areas of the code.

https://github.com/pyinstaller/pyinstaller/blob/86663765d8f370b9ae276db0e6370f05b2e737cc/PyInstaller/depend/utils.py#L92-L105



Discussion:
Well spotted, thanks! The base python location is even more invariant than the virtual environment location, which makes this even harder to notice.

I guess the real challenge here is getting `strip_paths_in_code` imported without causing import cycles between PyInstaller's modules...

Resolving patch:
diff --git a/PyInstaller/depend/utils.py b/PyInstaller/depend/utils.py
--- a/PyInstaller/depend/utils.py
+++ b/PyInstaller/depend/utils.py
@@ -49,6 +49,10 @@ def create_py3_base_library(libzip_filename, graph):
     modules is necessary to have on PYTHONPATH for initializing libpython3
     in order to run the frozen executable with Python 3.
     """
+    # Import strip_paths_in_code locally to avoid cyclic import between
+    # building.utils and depend.utils (this module); building.utils
+    # imports depend.bindepend, which in turn imports depend.utils.
+    from ..building.utils import strip_paths_in_code
     # Construct regular expression for matching modules that should be bundled
     # into base_library.zip.
     # Excluded are plain 'modules' or 'submodules.ANY_NAME'.
@@ -102,7 +106,8 @@ def create_py3_base_library(libzip_filename, graph):
                                 fc.write(source_hash)
                             else:
                                 fc.write(struct.pack('<II', timestamp, size))
-                            marshal.dump(mod.code, fc)
+                            code = strip_paths_in_code(mod.code)  # Strip paths
+                            marshal.dump(code, fc)
                             # Use a ZipInfo to set timestamp for deterministic build
                             info = zipfile.ZipInfo(new_name)
                             zf.writestr(info, fc.getvalue())


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
Error about exe runing on another computer:ImportError:DLL load failed
Traceback (most recent call last):
  File "profit_3.0.py", line 2, in <module>
  File "c:\users\zpf\appdata\local\programs\python\python37\lib\site-packages\Py
Installer\loader\pyimod03_importers.py", line 493, in exec_module
  File "wx\__init__.py", line 17, in <module>
  File "c:\users\zpf\appdata\local\programs\python\python37\lib\site-packages\Py
Installer\loader\pyimod03_importers.py", line 493, in exec_module
  File "wx\core.py", line 12, in <module>
ImportError: DLL load failed: 找不到指定的模块。



Discussion:
Have you tried installing [VC redistributable](https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0) on the target computer?
> Have you tried installing [VC redistributable](https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0) on the target computer?

I tried download and installing VC 2015,but it not works
What's the Windows version on the build and the target machine, then?

And what is the python version, and the wxPython version?
> What's the Windows version on the build and the target machine, then?
> 
> And what is the python version, and the wxPython version?

Windows version on both build and target computer is windows 10,python version 3.7,wxpython version 4.0.3 
What's the full python version, i.e., 3.7.x?
> What's the full python version, i.e., 3.7.x?

python 3.7.8.rcl
I think I've managed to reproduce this - in my case, building with wxpython 4.0.3 results in missing `msvcp140.dll`. 

Copying it from `c:\windows\system32` on the build machine to the application's dir should do the trick. 

As should installing [`Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019`](https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0) on the target machine. 
And as a side note, it seems to work out-of-the box with wxpython 4.1.1, presumably because it bundles its own copy of `msvcp140.dll`.

Resolving patch:
diff --git a/PyInstaller/depend/dylib.py b/PyInstaller/depend/dylib.py
--- a/PyInstaller/depend/dylib.py
+++ b/PyInstaller/depend/dylib.py
@@ -97,6 +97,14 @@
     r'ucrtbase\.dll',
     r'vcruntime140\.dll',
 
+    # Additional DLLs from VC 2015/2017/2019 runtime. Allow these to be
+    # collected to avoid missing-DLL errors when the target machine does
+    # not have the VC redistributable installed.
+    r'msvcp140\.dll',
+    r'msvcp140_1\.dll',
+    r'msvcp140_2\.dll',
+    r'vcruntime140_1\.dll',
+
     # Allow pythonNN.dll, pythoncomNN.dll, pywintypesNN.dll
     r'py(?:thon(?:com(?:loader)?)?|wintypes)\d+\.dll',
 }


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
Problem with scikitimage and _rolling_ball_cy
Hello Everyone,

When I run exe file on my computer everything works ok but when I try to run on virtual machine I get the error  File "skimage\restoration\rolling_ball.py", line 3, in <module>
ImportError: DLL load failed while importing _rolling_ball_cy: The specified module could not be found.
[2244] Failed to execute script Diopomat

I was trying to add by --hidden-import --hidden-import "skimage.restoration._rolling_ball_cy"
I have spent a couple of hours to resolve this problem but I had to give up :(
Please help me, how to fix it.

Best regards
Pavel 


Discussion:
Sounds like your VM needs [Visual Studio 2015 / 2017 / 2019 redistributable](https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0) installed.

We recently merged a commit that might help with vcredist DLLs (#5770); but I suspect that in this particular case, it is `vcomp140.dll` that's missing, so we'll need to add it to that list...

Resolving patch:
diff --git a/PyInstaller/depend/dylib.py b/PyInstaller/depend/dylib.py
--- a/PyInstaller/depend/dylib.py
+++ b/PyInstaller/depend/dylib.py
@@ -104,6 +104,7 @@
     r'msvcp140_1\.dll',
     r'msvcp140_2\.dll',
     r'vcruntime140_1\.dll',
+    r'vcomp140\.dll',
 
     # Allow pythonNN.dll, pythoncomNN.dll, pywintypesNN.dll
     r'py(?:thon(?:com(?:loader)?)?|wintypes)\d+\.dll',


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
fix_exe_for_code_signing() should increase the vmsize field of the LINKEDIT segment
## Description of the issue

### Context information (for bug reports)

* Output of `pyinstaller --version`: ```pyinstaller 4.4```
* Version of Python: 3.8.11
* Platform: macOS 11.4 Big Sur
* How you installed Python: Homebrew
* Not tried it on any other platform as it is relevant for macOS only.

This is not really a bug in the "normal" sense as PyInstaller works correctly in general; however, there is a comment in the `fix_exe_for_code_signing()` function in `utils/osx.py` that ponders whether the `vmsize` field of the `LINKEDIT` segment should be increased or it is enough to increase the `filesize` field. I would like to point out that the `vmsize` field should be increased as well; this can be confirmed by looking at the source code of `dyld`, which clearly complains if the `vmsize` is smaller than the `filesize` (see the source code [here](https://opensource.apple.com/source/dyld/dyld-852/src/ImageLoaderMachO.cpp.auto.html), search for `is larger than vmsize`).

The reason why it still works with PyInstaller-generated executables (I think) is because adding the code signature with `codesign` _after_ the executable was tweaked with `fix_exe_for_code_signing()` will adjust the `vmsize` appropriately so it becomes larger than `filesize` and also becomes aligned to the page size (4096 bytes). However, it would be better if the code did not rely on a later call `codesign` to fix the headers and just produced a valid executable when returning from `fix_exe_for_code_signing()`.


Discussion:

Resolving patch:
diff --git a/PyInstaller/utils/osx.py b/PyInstaller/utils/osx.py
--- a/PyInstaller/utils/osx.py
+++ b/PyInstaller/utils/osx.py
@@ -15,6 +15,7 @@
 """
 
 import os
+import math
 import shutil
 
 from PyInstaller.compat import base_prefix, exec_command_all
@@ -219,15 +220,16 @@ def fix_exe_for_code_signing(filename):
     symtab_sec.strsize += delta
     # .. as well as its parent __LINEDIT segment
     linkedit_seg.filesize += delta
-    # FIXME: do we actually need to adjust in-memory size as well? It
-    # seems unnecessary, as we have no use for the extended part being
-    # loaded in the executable's address space...
-    #linkedit_seg.vmsize += delta
+    # Compute new vmsize by rounding filesize up to full page size
+    page_size = (0x4000 if _get_arch_string(header.header).startswith('arm64')
+                 else 0x1000)
+    linkedit_seg.vmsize = \
+        math.ceil(linkedit_seg.filesize / page_size) * page_size
 
     # NOTE: according to spec, segments need to be aligned to page
     # boundaries: 0x4000 (16 kB) for arm64, 0x1000 (4 kB) for other arches.
     # But it seems we can get away without rounding and padding the segment
-    # size - perhaps because it's the last one?
+    # file size - perhaps because it is the last one?
 
     # Write changes
     with open(filename, 'rb+') as fp:


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
Pyinstaller leaks key when using with GitHub action secrets 
When using with GitHub action secrets, pyinstaller prints the key parameter into the console, a solution to this would be an additional argument to suppress the using key output. In this case the test key is 
```
[=?)K]P=`D!B,T}
```
https://github.com/illusion0001/py-patcher/runs/5439402984?check_suite_focus=true#step:4:19

https://github.com/pyinstaller/pyinstaller/blob/c95dba86673cba819558a0c6218e934095d87ac9/PyInstaller/building/build_main.py#L289

To something like
```py
logger.info('--hide-key is used, key will be hidden.')
```
Perhaps it might be a good idea to not leave string reference to the key, and write just the variable?
https://github.com/pyinstaller/pyinstaller/blob/c95dba86673cba819558a0c6218e934095d87ac9/PyInstaller/building/build_main.py#L294


Discussion:
In what scenario are your build logs public but your source code is private?
Well, to be fair, there's no real need to print the key in the debug message. (Or the message could be downgraded to debug instead of info, so it is not shown by default).
> In what scenario are your build logs public but your source code is private?

The source is here, https://github.com/illusion0001/py-patcher. tried testing keys and noticed it was being printed out
> Well, to be fair, there's no real need to print the key in the debug message.

Yeah, I agree. I guess that what I really wanted to say is that, since the bytecode encryption feature is mostly smoke and mirrors (the encryption key has to be part of the executable where anyone who knows where to look can find it), if you're seriously concerned about that encryption key getting leaked then the PyInstaller's encryption feature is inadequate for your needs anyway.

Resolving patch:
diff --git a/PyInstaller/building/build_main.py b/PyInstaller/building/build_main.py
--- a/PyInstaller/building/build_main.py
+++ b/PyInstaller/building/build_main.py
@@ -286,7 +286,7 @@ def __init__(
         self.custom_runtime_hooks = runtime_hooks or []
 
         if cipher:
-            logger.info('Will encrypt Python bytecode with key: %s', cipher.key)
+            logger.info('Will encrypt Python bytecode with provided cipher key')
             # Create a Python module which contains the decryption key which will be used at runtime by
             # pyi_crypto.PyiBlockCipher.
             pyi_crypto_key_path = os.path.join(CONF['workpath'], 'pyimod00_crypto_key.py')


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
UPX NotCompressibleException on PyInstaller 5.0
Trying to upgrade to version 5.0 from 4.10 and getting this error:
```
137113 INFO: Executing - upx--lzma-qC:\users\root\AppData\Local\pyinstaller\bincache01_py38_64bit\tornado\speedups.cp38-win_amd64.pyd
The subprocess:
    upx--lzma-qC:\users\root\AppData\Local\pyinstaller\bincache01_py38_64bit\tornado\speedups.cp38-win_amd64.pyd
exited with error 1 and error output:
                           Ultimate Packer for eXecutables
                              Copyright (C) 1996 - 2020
    UPX 3.96w       Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 23rd 2020

            File size         Ratio      Format      Name
       --------------------   ------   -----------   -----------
    upx: C:\users\root\AppData\Local\pyinstaller\bincache01_py38_64bit\tornado\speedups.cp38-win_amd64.pyd: NotCompressibleException

    Packed 1 file: 0 ok, 1 error.
````

* Output of `pyinstaller --version`: ```5.0```
* Version of Python: 3.8
* Platform: Windows (wine)
* How you installed Python: python.org (wine docker)
* Works on Linux and macOS



Discussion:
#6735 has accidentally promoted UPX failures to errors. I didn't realise that `PyInstaller.compat.exec_command()` ignores the return code of subprocesses.
@bwoodsend Thanks for the quick response, is there a fix coming up soon? 

Resolving patch:
diff --git a/PyInstaller/building/utils.py b/PyInstaller/building/utils.py
--- a/PyInstaller/building/utils.py
+++ b/PyInstaller/building/utils.py
@@ -22,7 +22,6 @@
 import struct
 import subprocess
 import sys
-import textwrap
 
 from PyInstaller import compat
 from PyInstaller import log as logging
@@ -365,12 +364,7 @@ def checkCache(
 
     if cmd:
         logger.info("Executing - " + "".join(cmd))
-        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True)
-        if p.returncode:
-            raise SystemExit(
-                f"The subprocess:\n    {''.join(cmd)}\nexited with error {p.returncode} and error "
-                "output:\n" + textwrap.indent(p.stdout, "    ")
-            )
+        subprocess.run(cmd, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
 
     # update cache index
     cache_index[basenm] = digest


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
PyInstaller docs wrong links to issues in Change Log
https://pyinstaller.org/en/v5.0/CHANGES.html
On this page, the github issues link are wrongly set as `https://github.com/%7Bgroup%7D/%7Bproject%7D/issues/#6089` instead of `https://github.com/pyinstaller/pyinstaller/issues/6089`.


Discussion:

Resolving patch:
diff --git a/doc/conf.py b/doc/conf.py
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -74,6 +74,8 @@
               'sphinxcontrib.towncrier',
               'sphinx_issues']
 
+issues_github_path = "pyinstaller/pyinstaller"
+
 intersphinx_mapping = {
     'python': ('https://docs.python.org/3', None),
     'matplotlib': ('https://matplotlib.org/stable/', None),


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
Docstrings of `exec_statement` and `eval_statement` have a note with an incorrect version number
## Description of the issue

This is a documentation issue.

The docstrings of `exec_statement` and `eval_statement` in `PyInstaller.utils.hooks` contains the following note:

    Notes:
        As of v4.6.0, usage of this function is discouraged in favour of the
        new :mod:`PyInstaller.isolated` module.

However, the `PyInstaller.isolated` module does not exist in versions 4.6-4.10. It is only available starting from 5.0.


Discussion:

Resolving patch:
diff --git a/PyInstaller/utils/hooks/__init__.py b/PyInstaller/utils/hooks/__init__.py
--- a/PyInstaller/utils/hooks/__init__.py
+++ b/PyInstaller/utils/hooks/__init__.py
@@ -88,7 +88,7 @@ def exec_statement(statement):
         datas = [ (mpl_data_dir, "") ]
 
     Notes:
-        As of v4.6.0, usage of this function is discouraged in favour of the
+        As of v5.0, usage of this function is discouraged in favour of the
         new :mod:`PyInstaller.isolated` module.
 
     """
@@ -158,7 +158,7 @@ def eval_statement(statement):
          hiddenimports.append("sqlalchemy.databases." + db)
 
     Notes:
-        As of v4.6.0, usage of this function is discouraged in favour of the
+        As of v5.0, usage of this function is discouraged in favour of the
         new :mod:`PyInstaller.isolated` module.
 
     """


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
user-provided matplotlib backend names list causes TypeError: unhashable type: 'list'
## Description of the issue

* Output of `pyinstaller --version`: ```5.4.1```
* Version of Python: 3.7.9
* Platform: Windows 10

When implementing the matplotliib backend hook configuration example in the docs:

```
a = Analysis(
    ["my-matplotlib-app.py"],
    ...,
    hooksconfig={
        "matplotlib": {
            #"backends": "auto",  # auto-detect; the default behavior
            # "backends": "all",  # collect all backends
            # "backends": "TkAgg",  # collect a specific backend
            "backends": ["TkAgg", "Qt5Agg"],  # collect multiple backends
        },
    },
    ...,
)
```

I get the following exception:

```
  File "C:\Users\...\lib\site-packages\PyInstaller\hooks\hook-matplotlib.backends.py", line 192, in hook
    logger.info("Matplotlib backend selection method: %s", _method_names.get(backends_method, 'user-provided name(s)'))
TypeError: unhashable type: 'list'

```
I think perhaps this is just an issue with the logger.info call?

I'm very inexperienced with GitHub sorry, otherwise I would try to submit a PR.




Discussion:

Resolving patch:
diff --git a/PyInstaller/hooks/hook-matplotlib.backends.py b/PyInstaller/hooks/hook-matplotlib.backends.py
--- a/PyInstaller/hooks/hook-matplotlib.backends.py
+++ b/PyInstaller/hooks/hook-matplotlib.backends.py
@@ -185,18 +185,15 @@ def hook(hook_api):
     if backends_method is None:
         backends_method = 'auto'  # default method
 
-    _method_names = {
-        'auto': 'automatic discovery of used backends',
-        'all': 'collection of all importable backends',
-    }
-    logger.info("Matplotlib backend selection method: %s", _method_names.get(backends_method, 'user-provided name(s)'))
-
     # Select backend(s)
     if backends_method == 'auto':
+        logger.info("Matplotlib backend selection method: automatic discovery of used backends")
         backend_names = _autodetect_used_backends(hook_api)
     elif backends_method == 'all':
+        logger.info("Matplotlib backend selection method: collection of all importable backends")
         backend_names = _collect_all_importable_backends(hook_api)
     else:
+        logger.info("Matplotlib backend selection method: user-provided name(s)")
         if isinstance(backends_method, str):
             backend_names = [backends_method]
         else:


Test patch:
Repository: pyinstaller/pyinstaller

Issue:
pyi-grab_version creates broken file on certain.
On certain exe files in the system32 folder (e.g. winrshost.exe), when you use the command `pyi-grab_version` to get the version file, the file generated would be broken if the description of the exe contains `'`. Like in winrshost.exe's case, the description of the version file would be `StringStruct('FileDescription', 'Host Process for WinRM's Remote Shell plugin')`
Which gives `SyntaxError: unterminated string literal` due to the unescaped single quote.


Discussion:

Resolving patch:
diff --git a/PyInstaller/utils/win32/versioninfo.py b/PyInstaller/utils/win32/versioninfo.py
--- a/PyInstaller/utils/win32/versioninfo.py
+++ b/PyInstaller/utils/win32/versioninfo.py
@@ -451,7 +451,7 @@ def __eq__(self, other):
         return self.toRaw() == other
 
     def __str__(self, indent=''):
-        return "StringStruct('%s', '%s')" % (self.name, self.val)
+        return "StringStruct(%r, %r)" % (self.name, self.val)
 
     def __repr__(self):
         return 'versioninfo.StringStruct(%r, %r)' % (self.name, self.val)


Test patch:
diff --git a/tests/unit/test_miscutils.py b/tests/unit/test_miscutils.py
--- a/tests/unit/test_miscutils.py
+++ b/tests/unit/test_miscutils.py
@@ -81,6 +81,43 @@ def test_versioninfo_str(tmp_path):
     assert vsinfo == vsinfo2
 
 
+# Test that we properly serialize and deserialize VersionInfo that contains strings with quotes, such as the
+# `FileDescription`  of `winrshost.exe` being `Host Process for WinRM's Remote Shell plugin`. See #7630.
+@pytest.mark.win32
+def test_versioninfo_str_quotes(tmp_path):
+    from PyInstaller.utils.win32.versioninfo import VSVersionInfo, \
+        FixedFileInfo, StringFileInfo, StringTable, StringStruct, \
+        VarFileInfo, VarStruct
+
+    FILE_DESCRIPTION = """versioninfo with quotes (' and ") test"""
+
+    vsinfo = VSVersionInfo(
+        ffi=FixedFileInfo(
+            filevers=(1, 2, 3, 4),
+            prodvers=(5, 6, 7, 8),
+            mask=0x3f,
+            flags=0x1,
+            OS=0x40004,
+            fileType=0x42,
+            subtype=0x42,
+            date=(0, 0)
+        ),
+        kids=[
+            StringFileInfo([StringTable('040904b0', [StringStruct('FileDescription', FILE_DESCRIPTION)])]),
+            VarFileInfo([VarStruct('Translation', [1033, 1200])])
+        ]
+    )
+
+    # "Serialize" to string. This is what grab_version.py utility does to write VsVersionInfo to output text file.
+    vs_info_str = str(vsinfo)
+
+    # "Deserialize" via eval. This is what `versioninfo.load_version_info_from_text_file` does to read `VsVersionInfo`
+    # from text file.
+    vsinfo2 = eval(vs_info_str)
+
+    assert vsinfo == vsinfo2
+
+
 @pytest.mark.win32
 def test_versioninfo_written_to_exe(tmp_path):
     from PyInstaller.utils.win32 import versioninfo