Skip to content
This repository has been archived by the owner on Apr 4, 2024. It is now read-only.

FAHControl won't start on Fedora 31 (Python 3 by default) [workaround] #61

Open
gloomytrousers opened this issue Mar 27, 2020 · 13 comments
Labels

Comments

@gloomytrousers
Copy link

Installed fahcontrol-7.5.1-1.noarch on Fedora 31 x86_64. It won't start:

  File "/usr/bin/FAHControl", line 57
    if sock.recv(1024).strip() == 'OK': print 'Ok'
                                                 ^
SyntaxError: invalid syntax

This appears to be because Fedora defaults to Python 3 and FAH needs Python 2.

Workaround: run this from a terminal:

python2 /usr/bin/FAHControl

Or edit the first line of /usr/bin/FAHControl to:

#!/usr/bin/python2

(add the 2)

This is the same as #50 which was opened and then immediately closed. See also #39, #53, #56.

@shorttack
Copy link

Please try the Linux beta at https://foldingathome.org/beta/ and report back here if you are still having this difficulty.
Issue Support

@gloomytrousers
Copy link
Author

Tried the beta (fahclient-7.6.6-1.x86_64), same result.

@shorttack shorttack added the bug label Apr 14, 2020
@shorttack
Copy link

Tried the beta (fahclient-7.6.6-1.x86_64), same result.
Thanks, @gloomytrousers
Bug

@deragon
Copy link

deragon commented Apr 17, 2020

I do not have Fedora 31, but from the description of this bug, seams that /usr/bin/python is a symlink to Python 3. That would explain the syntax error. Can you please check this out?

@jwesterd-redhat
Copy link

jwesterd-redhat commented Apr 18, 2020 via email

@gloomytrousers
Copy link
Author

@deragon Yes /usr/bin/python is indeed a symlink to python3.

@jwesterdale-rh Yes I changed the script as indicated (see original report), which makes it work. What do you mean by "newer versions"? I've just upgraded to the latest beta (fahcontrol-7.6.10-1.noarch) and the problem still exists.

@deragon
Copy link

deragon commented Apr 18, 2020

I have the latest version of FAH and I confirmed that it is still coded for Python 2. @jwesterdale-rh, solution to replace the first line of the scripts with #!/usr/bin/env python2 is the way to go. This change should go into the code right now and stay there until the code is converted to Python 3. Any FAH developer reading this? It would be a very simple fix to include.

@shorttack
Copy link

Any FAH developer reading this? It would be a very simple fix to include.

@abitrolly
Copy link
Contributor

Interesting that FAHControl in repository contains the right #!/usr/bin/env python2 shebang.
https://github.com/FoldingAtHome/fah-control/blob/master/FAHControl#L1
But inside .rpm it is already different.

$ mkdir files
$ rpm2cpio fahcontrol-7.6.9-1.noarch.rpm | cpio -D files/ -idmv
$ head files/usr/bin/FAHControl -n 1
#!/usr/bin/python

abitrolly added a commit to abitrolly/fah-control that referenced this issue Apr 24, 2020
This might fix broken `FAHControl` on Fedora (FoldingAtHome#61)
@cdberkstresser
Copy link

@gloomytrousers We do have rpms and debs for PR #70, which is definitely a work in progress. It is what I've used to do the beta testing for FAHClient from Ubuntu 20.04 and Fedora 31 when I needed FAHControl to see what was going on.
https://github.com/cdberkstresser/fah-control/releases

@abitrolly
Copy link
Contributor

@gloomytrousers while Python 3 is not ready, is it possible to release a quick fix for Fedora .rpms to explicitly depend on Python 2?

@stealth-swift
Copy link

Python2 support is now End Of Life as of January 1st 2020 and should be depreciated ref: https://www.python.org/doc/sunset-python-2/
As a consequence of this, all Linux distributions are gradually transitioning to dropping support for Python2, having Python3 be set default on install. Already Python2 is harder to find/install from some distribution repositories including Ubuntu & Mint which are seen as the more 'beginner friendly' and hence have a generally larger user base. The next LTS releases of all major distros will probably be Python2 depreciated and default to Python3 only. Whilst general transition from Python2 to Python3 has taken a while due to inertia by a large historical codebase, impetus to upgrade has now been accelerated this year by Python2 EOL status and the actions of the distribution maintainers.

I suggest 'workaround' options be limited in scope as much as possible so as to concentrate developer focus towards bringing all FAH components to depreciate requirement of Python2 and instead upgrade to mainline for Python3. There will be a lot of variance in knowledge of the Linux user base and this issue is already causing FAH installation issues on newer distros as a consequence. Anything that hinders potential adoption of FAH or the continuation of it's use when a supporter upgrades their core OS should be mitigated against, and a current continuing requirement of Python2 has general security implications going forward.

@abitrolly
Copy link
Contributor

@stealth-swift @FoldingAtHome folks don't care and fail to increase their capacity.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

7 participants