Inability to package untill PyInstaller provides support for Python 3.8

[gridhead]

This might need your attention @lcts. There is stuff changed in one of the branches which do not run on Fedora 32 Workstation when they are packaged into an executable binary by PyInstaller. On searching deep, I figured that it is the Python version to blame as PyInstaller does not provide support for Python 3.8 (or above).

Any solution for this?

[lcts]

Sort of. Apparently, 3.8 support will be in PyInstaller 4.1, which should be available soon, or you can try their development branch. I don't know how likely it is that the latter will cause other problems with the created binaries, but given that the devs deem 4.1 almost ready, it should be fine.

However, personally, I'd say it makes more sense to ditch the binary and focus exclusively on packaging as RPM - the installer isn't portable to non-Fedora/CentOS systems anyway.

[gridhead]

True. Plus check this out. Dropping the executable binaries would help me to not worry about distro identification and handling as I can be sure that the package (in COPR) would only be accessible in places where it is supposed to run. I guess, it is now time to say goodbye to our PyInstaller-based binaries. Once, the COPR is tested and confirmed to be working we might just phase them out slowly.

[gridhead]

I am keeping this open until we get a robust COPR (which we have now, the only thing needed is a version bump and a lot of rigorous QA testing) then we can slowly phase out the PyInstaller based binaries.

To-do

• Version bump the COPR and perform QA tests on devices
• Hit the mailing list to find folks interested to test this tool
• Rename the tags and binary versions as LEGACY to note phasing out
• Note the same on the README.md - preferably on Ask Fedora
• Create a Quick Docs to instruct the COPR method of installation

[lcts]

I rebuild the package on Copr from your master branch, so it now has the latest version (0.3.5). If you've previously installed it, you'll have to uninstall & reinstall to get the new package, because I messed up the version number in my branch (0.4 instead of 0.3), so the upgrade path is broken. I already removed the previous builds from the repo, so this is not an issue if you don't have the package installed.

[gridhead]

Let me check it real quick and confirm that to you.

@lcts, I uninstalled the package (dnf remove nvautoinstall) and ran an update (dnf update). Then I proceeded to install the package back (dnf install nvautoinstall) but I am still getting back the old version with the same dependencies. Was I supposed to remove the COPR repo and add it again or did I do it right?

[onuralpszr]

@t0xic0der do we need this or close this ? ( I am going to close but If you still want it, we can re-open but just let me know as well) (it just doing some cleanup nothing serious)