According to https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview: "We eventually intend to ship only Python 3 with the Ubuntu desktop image, not Python 2. This Ubuntu 13.04 Beta continues this process, although we will not be able to convert everything to Python 3 for Ubuntu 13.04." Also, according to https://wiki.ubuntu.com/Python/3: "It is a release goal for Ubuntu 14.04 LTS to have only Python 3 on the desktop CD images." Since LTS releases are potentially of interest for us in terms of recommended/tested distributions, perhaps we should discuss how this might affect ThinLinc on this platform.
Fedora are also aiming for only Python 3 in the default installation: https://fedoraproject.org/wiki/Changes/Python_3_as_Default
Also see bug 4867.
The Ubuntu 16.04 Beta default server installation does not include Python 2. It therefore also does not include python-apt by default, preventing automatic package installation. There are also no desktop alternatives in the server installer, so it might be that no option (except manually selecting the python package) gives you Python 2 during installation.
Ubuntu 16.04 Desktop version includes Python 2 by default at least, but not python-apt.
Bug 5742 has implemented checks for Python and PyGTK and tries to help the user install these. Platform Specific Notes have also been written for both Red Hat/Fedora and Ubuntu. SLE/openSUSE still ship Python 2 even in the minimal install so they do not need any action yet.
(In reply to comment #6) > Platform Specific Notes have also been written for both Red Hat/Fedora and > Ubuntu. Looks good.
More Ubuntu updates: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-December/001234.html
https://lwn.net/Articles/756628/
RHEL 8 beta is now out, and this is their position on Python: > Python 3.6 is the default Python implementation in RHEL 8; limited support for Python 2.7 is provided. No version of Python is installed by default. A bit problematic that we can't even assume Python 3 is installed going forward... More details here: https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/
Even more details about Python in RHEL 8: https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/ One thing that is missing is a clear indication when Red Hat will stop supporting Python 2.
"/usr/bin/python" now points to python 3 on Fedora 31. Python 2 will be removed in Fedora version 32: https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
*** Bug 4867 has been marked as a duplicate of this bug. ***
Is there any new progress on this issue? Archlinux is also currently removing python2 from its repos
Yes, it is something we intend to address in the coming releases.
I've checked the major tools for helping out with conversion, and they are: 2to3: The original tool from the Python project. Meant for a conversion from Python 2 only code to Python 3 only code. modernize: Variant of 2to3 that focuses on making Python 2 code compatible with Python 3. futurize: Another variant that builds on modernize, but reverses things and tries to make Python 3 code compatible with Python 2. As we have no interest in keeping Python 2 compatibility it seems like 2to3 is the main tool for us. One major gotcha about it is that it stays clear of the mess around divisions. So those will need to be manually inspected when we convert things.
Cheetah3 only supports Python 2.7 and Python 3.4 and newer. This means that in order to use Cheetah3 we need to take this into consideration. Documentation for Cheetah3 updates: https://cheetahtemplate.org/news.html See bug 7553.
Apparently 2to3 doesn't enable all its fixers by default (despite what --help says). We probably want to use this line: > 2to3 -f all -f buffer -f idioms -f set_literal
One question is what version of Python 3 we should require. Red Hat are using 3.6 for RHEL 7 and 3.8 for RHEL 8. Ubuntu has 3.5 for 16.04, 3.6 for 18.04 and 3.8 for 20.04. SUSE has 3.4 for SLE 12 and 3.6 for SLE 15. So it looks like 3.4 is the newest version we can require if we want to support all currently supported versions of the enterprise distributions.
Python 3 now requires unicode strings for many system APIs (e.g. getpwnam()), so we need to start removing calls to locale_encode()/locale_decode() as part of the conversion. Fortunately Python 3 behaves like we want, so users will get the same functionality.
When using development mode to catch issues, we also get this junk on stop: > Debug memory block at address p=0x275cad0: API '0' > 17293822569102704640 bytes originally requested > The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfd): > at p-7: 0x00 *** OUCH > at p-6: 0x00 *** OUCH > at p-5: 0x00 *** OUCH > at p-4: 0x00 *** OUCH > at p-3: 0x00 *** OUCH > at p-2: 0x00 *** OUCH > at p-1: 0x00 *** OUCH > Because memory is corrupted at the start, the count of bytes requested > may be bogus, and checking the trailing pad bytes may segfault. > The 8 pad bytes at tail=0xf00000000275cad0 are followed by a segfault. This is some kind of bug in Python 3.8+. I've reported it upstream, but for now we'll just have to ignore it: https://bugs.python.org/issue42540
Right now we have a deprecation warning when loading licenses. This should be fixed when we remove Python 2 support from LicenseHandler. We could not do this when solving bug 7630 since tl-collect-licensestats needs Python 2 support. > 2021-04-15 09:05:20 INFO vsmserver.license: Updating license data from disk to memory > /opt/thinlinc/modules/thinlinc/vsm/licensehandler.py:387: DeprecationWarning: This method will be removed in future versions. Use 'parser.read_file()' instead. > I1iiIII1i . readfp ( iII11iI1i ) > 2021-04-15 09:05:20 INFO vsmserver.license: License summary: 50 concurrent users. Hard limit of 55 concurrent users.
We have some hacks to clean out old .pyc files in tlsetup.py and thinlinc-tlmisc.spec.in. As we no longer use Python 2 we can remove those.
Tested tl-session-param on a Fedora 33 server after conversion to Python 3. Works good but I get the following resource warning from prefix.py: >[cendio@lab-143 bin]$ python3 -Xdev -Xtracemalloc=5 tl-session-param -a >/client_params/ >/opt/thinlinc/modules/thinlinc/prefix.py:75: ResourceWarning: unclosed file <_io.TextIOWrapper name='/var/opt/thinlinc/sessions/cendio/11/sessnum' mode='r' >encoding='UTF-8'> > I1I1 = open ( Ooo0OO ) . read ( ) >Object allocated at (most recent call last): > File "/opt/thinlinc/bin/tl-session-param", lineno 143 > IIiIiiIiI ( ) > File "/opt/thinlinc/bin/tl-session-param", lineno 104 > i1I11ii = get_public_sessioninfo ( oOo0O00O0ooo ) > File "/opt/thinlinc/modules/thinlinc/sessioninfo.py", lineno 190 > display = prefix . get_tl_sessnum ( oO00OOooOoO0o ) > File "/opt/thinlinc/modules/thinlinc/prefix.py", lineno 75 > I1I1 = open ( Ooo0OO ) . read ( )
I have done some cleanup in vsm.extproc, vsm.subcluster and vsm.uid_gid_util. I also deleted the thinlinc.locale module since it's not needed anymore. I have now tested the effected areas. Tested extproc on RHEL 8: ✓ Session startup scripts are run. ✓ Unbind ports works. ✓ License warning mail sent to admin. To make sure that the last parts of thinlinc.locale was successfully removed I tested some non-ASCII handling on Ubuntu 20.10: ✓ User 't€stör' can create a session. ✓ If 't€stör' tries to shadow a session when not allowed the name is printed correct in the log. ✓ If 't€stör' is associated with a subcluster by name, the correct subcluster is chosen when starting a new session. I also grepped for 'locale_encode' and 'locale_decode' in the installed ThinLinc tree. Found nothing.
I can verify that tl-sso-fromfile and tl-sso-sendkeys has been successfully removed from the product and no traces are left of the scripts.
Tested tl-wait-smartcard on Ubuntu 20.04: ✓ No client smart card support (webaccess) ✓ Waiting for reader (manually delayed client connection) ✓ Timeout
Tested tl-memberof-group on Ubuntu 20.04: ✓ Invalid group ✓ Group not member of ✓ Primary group ✓ Secondary group ✓ Multiple groups, all wrong ✓ Multiple groups, one matching
Tested tl-collect-licensestats on Ubuntu 20.10. ✓ License log is correct ✓ Correct license info is shown in tlwebadm/status Also tested some general license handling. ✓ License warning mail sent to admin ✓ Blocking new users when hitting hard limit ✓ Loading license files
Tested tl-env on Ubuntu 20.10: ✓ Missing xstartup.env ✓ Invalid display ✓ Default options ✓ Explicit display ✓ Exclude $DISPLAY
Tested tl-session-param on Fedora 34. Works fine ✓ Listing all parameters ✓ Listing values and directories ✓ Printing for environment variable ✓ Not a folder ✓ No such parameter ✓ Using option -e on a folder Also made sure there are no resource warnings as mentioned by Niko in comment #41.
The Python 2 support has now been removed from thinlinc.authutil, thinlinc.kdf and thinlinc.crypt. I have tested that the modules still works as intended on Fedora 34. ✓ Logging in with tlwebaccess ✓ auth_cookie looks random and works ✓ tlwebadm password look random and works ✓ tl-gen-auth ✓ tl-sso-update-password ✓ tl-sso-password
Tested this on Fedora 34: ✓ tl-sso-update-password (non-ASCII) ✓ tl-sso-password (non-ASCII) This means that the sso module is tested after Python 2 support was removed.
Asyncbase's Python 2 support has been removed and I have tested this to make sure everything works as before: ✓ General session handling (Create, Reconnect, terminate) ✓ Stopping/starting vsmagent/vsmserver ✓ Delayed calls, periodic update of load info ✓ Terminated session cleanup Tested build 2199 on Fedora 34.
Tested thinlinc.prefix after cleanup on SLES 12: ✓ tl-mount-localdrives works (uses get_tl_sessnum())
Tested thinlinc.sessinfo after cleanup on SLES 12: ✓ Agent hostname (IP) correctly detected ✓ tl-mount-localdrives (fetches session info)
Tested thinlinc.crypto after cleanup on SLES 12: ✓ Valid licenses work ✓ Manipulated licenses are rejected
Tested thinlinc.selinux after cleanup on RHEL 8: ✓ Everything is correctly configured by tlsetup (users, module, file contexts)
Running grep with the patterns attached in comment 116 on the non-vendor parts of the tree now only results in a bunch of false positives. We can therefore conclude this long journey towards a fully Python 3 converted ThinLinc. Marking as closed.
