Bug report: upx: actions-runner: vtkrenderingfreetype-9.2.dll about nuitka HOT 9 OPEN

Sorry to disturb, I found my ignorance blinded me, I fixedit by adding echo PATH=$PATH >> $GITHUB_ENV when creating venv.

from nuitka.

You ought to use Nuitka-Action, as an aside. https://github.com/Nuitka/Nuitka-Action

With wrong PATH I would have expected it to not find upx at all and error exit with an absence message, since it checks that binary to exist. To me OSError: [Errno 22] Invalid argument might be AV or UPX holding a lock after execution still, but I am not sure of that. In that case, it might be a race. Need to see if it repeats. Your machine might do strange things there, and we have used extra balls for actions subjected to AV before.

from nuitka.

The AV interfering, much like it does with C compile build results, would make the most sense. Due to caching, it probably also becomes very unlikely to happen, so no urgency there, esp. as the UPX plugin is not the most important of them all.

from nuitka.

Thank you very much.
Due to hardware problems, Hyper-V cannot be started (As an aside: wsl2 does not boot but wsl1 does on my server) on my server with actions-runner installed. Therefore, when I actually use Nuitka/[email protected], the following error will occur in github action:

Run Nuitka/[email protected]
  with:
    nuitka-version: main
    script-name: qt_run.py
    standalone: true
    enable-plugins: pyside6
    working-directory: .
    onefile: true
    assume-yes-for-downloads: true
    output-dir: build
Run echo "NUITKA_CACHE_DIR=D:\actions-runner\_work\_actions\Nuitka\Nuitka-Action\v1.1/nuitka/cache" >> $GITHUB_ENV
  echo "NUITKA_CACHE_DIR=D:\actions-runner\_work\_actions\Nuitka\Nuitka-Action\v1.1/nuitka/cache" >> $GITHUB_ENV
  echo "PYTHON_VERSION=$(python --version | awk '{print $[2](https://github.com/MWTJC/GBT_Calculator/actions/runs/7735414040/job/21091036565#step:2:2)}' | cut -d '.' -f 1,2)" >> $GITHUB_ENV
  shell: C:\Windows\System[3](https://github.com/MWTJC/GBT_Calculator/actions/runs/7735414040/job/21091036565#step:2:3)2\bash.EXE --noprofile --norc -e -o pipefail {0}
<3>WSL (230) ERROR: CreateProcessEntryCommon:[5](https://github.com/MWTJC/GBT_Calculator/actions/runs/7735414040/job/21091036565#step:2:5)02: execvpe /bin/bash failed 2
<3>WSL (230) ERROR: CreateProcessEntryCommon:505: Create process not expected to return
Error: Process completed with exit code 1.

So I had to run nuitka like a local command when using actions-runner.
In addition, I found that the upx compression failure I proposed was somewhat random. After further investigation, I found that it was related to windows defender, which would react to part of nuitka's upx cache and part of the dll after nuitka's upx compression. I guess a possible solution is for nuitka users to manually add upx compression exceptions to avoid build failures or windows defender reacting to built files for delivery while retaining some volume compression. I am trying to package the build files for delivery using NSIS. However, it is still impossible to avoid the large file size of the program after installation.
Thanks.

You ought to use Nuitka-Action, as an aside. https://github.com/Nuitka/Nuitka-Action

With wrong PATH I would have expected it to not find upx at all and error exit with an absence message, since it checks that binary to exist. To me OSError: [Errno 22] Invalid argument might be AV or UPX holding a lock after execution still, but I am not sure of that. In that case, it might be a race. Need to see if it repeats. Your machine might do strange things there, and we have used extra balls for actions subjected to AV before.

The AV interfering, much like it does with C compile build results, would make the most sense. Due to caching, it probably also becomes very unlikely to happen, so no urgency there, esp. as the UPX plugin is not the most important of them all.

from nuitka.

Your runner failing like that in the caching part, a well established component, it seems to be the problem with your runner, so I won't care much. I will handle my theory there, that some sort AV caused permission issue can exist for upx just like when we update resources, but I do not consider looking into your details which are entirely unreproducible to me and indicate a very strange setup with some sorts of limitations not commonly found.

from nuitka.

Yes, my usage scenario is far removed from the general usage scenario, so I will consult relevant documents to understand relevant knowledge first or try to use more usual usage to avoid this particular failure I encountered.
Thanks.

from nuitka.

Sorry for the waste of time, here is a follow-up note that has nothing to do with nuitka:
For Github action, everything works fine;
For my Windows actions-runner without sh support (not working even after using Vampire/setup-wsl), I solved the environment variable problem by using Poetry and replaced every python run with poetry run , and circumvented the upx plug-in problem by adding exclusion list in AV.
Thanks.
Shall I close this issue as not planned?

from nuitka.

If it's not already clear, I am ignoring your side of the issue here entirely. What I mean to do for this issue still, once I find the time of course, is to give the upx compressor extra balls when copying the compressed DLLs, since that is a theoretically true problem with Windows and AV. Your side of things is as invalid as it gets, but I don't care much in which ways your system is broken or repaired after knowing it is broken and your result is being invalid. That said, the problem I considered possible, I will try and make it solved still, but not now.

from nuitka.

I see.
All the best.
Thanks.

from nuitka.