Everything Python 2.x is heavily deprecated on Ubuntu 20.04, so they no longer ship PyGTK in any repo. We should move to something newer, and probably add a platform specific not until then.
Also note bug 7492 which makes this much worse.
This problem does not affect all new distros, Fedora 32 for example has this package: pygtk2-2.24.0-29.fc32.x86_64
A platform specific note has been added: https://www.cendio.com/thinlinc/docs/platforms/ubuntu Once a new release that includes the fix for bug 7492 is out we should modify the PSN with information about how ThinLinc is usable without PyGTK.
Release is out and PSN has been updated.
I also hit this issue after updating to Ubuntu 20.04 but found the following solution: https://askubuntu.com/questions/1235271/pygtk-not-available-on-focal-fossa-20-04 So IMHO you should better instruct your users to install the pygtk2 packages from the suggested PPA using the following procedure: sudo add-apt-repository ppa:nrbrtx/python2-stuff sudo apt-get install python-gtk2 And of course it would be IMHO better to finally update your profile chooser to python3 in future!
The workaround does not work. It has been quite some time since ubuntu 20.04 (or linux mint 20) has been released, is there any discussion or at least the timeline that thinlinc is going to address the pygtk2 issue? Otherwise, the community might have to turn to other solution.
I confirm that this will be an increasingly difficult challenge for us. A discussion of plan so we can determine future direction would be very useful. -- Steve Moulton - Systems Engineer Architectures and Performance Group Oak Ridge National Laboratory
We are in the midst of the huge Python 3 conversion project here, and it's too early to give any promises. But if all goes as planned we won't be requiring pygtk2 in the upcoming ThinLinc release, our hope is for the summer release to be entirely Python 2 free. Stay tuned.
@Samuel, @Pierre Thanks for the update and looking forward to see a python3 enabled ThinLinc soon! However, please allow me to raise again my general concerns here, that all this would probably not have happened (not being able to install ThinLinc on Ubuntu 20.04 LTS in 2021!) if you at cendio would open source at least parts of your ThinLinc product line. Especially the ThinLinc Client, the python-driven chooser, etc. are components which IMHO do not justify keeping them closed source or released after having obfuscated the code. If the ThinLinc Client or python-driven chooser would be available, e.g. on GitHub, under an appropriate open source license, then the community around it would have done the job already in porting to Python3 and you would have official support for Ubuntu 20.04 already! And unfortunately this isn't the first time that almost one year after an official Ubuntu LTS release, ThinLinc have to be manually patched by users to get it running, rather than seeing you releasing it officially for the new LTS version!
We've started looking at the specifics now. The logical replacement for pygtk2 is PyGObject. GObject dropped Python 2 support a few months ago in version 3.38.0 - (2020-09-12): https://pygobject.readthedocs.io/en/latest/changelog.html Since pygtk2 isn't available in Python3 we assume it would be best to move from pygtk2 to PyGObject _before_ moving from Python 2 to Python 3. PyGObject for Python2 isn't available in the regular repos, but is provided by pip2: $ wget https://bootstrap.pypa.io/pip/2.7/get-pip.py $ sudo python2 get-pip.py # Dependency: $ sudo dnf install gobject-introspection-devel $ python2 -m pip install pygobject The steps above gave us PyGObject 3.36.1, and it seems to work fine in Python 2.7.
The latest versions of PyGObject lists Python 3.6 as the required version. PyGObject's decision seems to be based on the fact that older Python versions are EOL. We will target Python 3.4 in ThinLinc for now, this could cause some problems if we try to mix old Python versions and new PyGObject versions. The version of PyGObject provided on SLES12 (which uses Python 3.4) is 3.20.1, which is from 2016. We have tested PyGObject on SLES12 and it seems to work fine. When porting from Pygtk2 to PyGObject we need to be careful not to use things from newer versions (newer than 3.20.1).
The GTK2 C API is available here, it might be useful when converting from Pygtk2 to PyGObject/GTK3: https://developer.gnome.org/gtk2/stable/ It should be easy to map the C functions and properties to the Python equivalents. The documentation for PyGObject 3.20.1 should be possible to build using this: https://gitlab.gnome.org/GNOME/pygobject/-/tree/pygobject-3-20/docs Once built, could we host it internally somehow? It doesn't seem to be available anywhere online.
We should try to keep an eye out for open bugs in the same area, some might get fixed along the way (on the buy!).
A survey of versions of GTK+ and friends on the older distributions: Distribution | GTK/GDK | GLib/GObject | Pango | python3-gobject | ------------------------------------------------------------------- Debian stretch | 3.22 | 2.50 | 1.40 | 3.22 | Ubuntu 16.04 | 3.18 | 2.48 | 1.38 | 3.20 | SLES 12 | 3.20 | 2.48 | 1.40 | 3.20 | RHEL 7 | 3.22 | 2.56 | 1.42 | 3.20* | ------------------------------------------------------------------- * From EPEL, only python2-gobject in the base distribution Support for Ubuntu 16.04 ends this month (April 2021), so it looks like GTK+ 3.20 will be our new base requirement.
For reference, GTK+ 3.20 has these requirements: * GLib >= 2.45.8 * Pango >= 1.37.3 * Cairo >= 1.14.0 Python GObject is not directly tied to GTK+ so it is unclear exactly what we require there. Version 3.20 was released together with GTK+ 3.20 so they should hopefully be properly matched.
`syscheck.sh' has now been modified to automatically install our required PyGObject dependencies instead of pygtk. This automatic installation process has been successfully tested on the following distributions: * RHEL8 * SLES12, SLES15 * Ubuntu 18.04, Ubuntu 20.04 * Debian 9 * Fedora 34. RHEL7 does not provide python3-gobject in the official repositories. This dependency can instead be obtained from EPEL. This will require an entry under "Platform specific notes".
All graphical parts of the server are now migrated from PyGTK/GTK2 to PyGObject/GTK3. The following scripts have been tested and seemingly works as intended on Fedora 33 (tested against Jenkins server-bundle #2064): - tl-run-xstartup-feedback - tl-setup - tl-select-profile - tl-ssh-askpass - tl-sso-update-password - tlinstaller
Please note that there are a couple of instances where unescaped unicode escape sequences leak into the GUI. This is expected and will get resolved once we transition to Python 3.
Reopening due to two minor issues: - `WrapLabel`, a GTK widget that we have opted to stop using when converted to GTK+3 has no usages, but its python implementation along with a couple of references to it in Makefiles and documentation still remain in the source tree. These should be removed. - We want to stay consistent with GTK naming. `Gtk.Window.parent` has been renamed to `Gtk.Window.transient_for`. We have already accounted for these changes in the GTK API, but references to the old name still remained in local variable names. These variable names should be changed.
The minor issues in comment 125 are now corrected. The following things are to be retested (there are quite a few distributions that still need to be tested, doing this for the remaining distributions will suffice since nothing dependent on the GTK or Python version has changed): - General functionality of all GUI script - The error dialog of `tlinstaller` and `tl-setup`. - Standalone script with a text entry dialog: - `tl-ssh-askpass` - `tl-sso-update-password`
I have tested with build 2066 on SLES 12 and SLES 15. Everything works fine on SLES 12, but on SLES 15 there is one odd scenario: 1. In tlsetup, before installing python dependencies the size of the windows is as expected. 2. When showing the progress bar for the installing of the dependencies, the window gets much wider, but keeps it height. Reproduce by having a fresh install of SLES 15 that requires python dependencies to be installed. If no dependencies needs to be installed, the window stays the correct size.
I have tested build 2066 on Ubuntu 18.04, Ubuntu 20.04 and RHEL 8. Found no problems. I also tested build 2068 on RHEL 7, CentOS 8 and Fedora 33, aside from the issue with xstartup-feedback (bug 7703) it also works mostly fine. I could not reproduce the issue mentioned in comment #129. On RHEL 7, there is no `python3-gobject` package, this is going to be problematic for customers using RHEL 7. The workaround is to install `python36-gobject` from EPEL. At the very least we need to add a platform specific note for this. I think we should do our best to point the admin in the correct direction here.
The issue described in comment 129 has now been corrected.
The installer is restarted after successfully completing both the installer and tl-setup. No obvious reason why, so let's take a guess that it is the changes here that has caused this. Seen on Ubuntu 20.04.
The issue described in comment 135 was found to be a side-effect of the fix for bug #7671. Marking as resolved once again.
As highlighted in comment 132, EPEL uses the name `python36-gobject` instead of `python3-gobject`. We have settled on assuming that EPEL is installed on all RHEL7 systems. Assuming that EPEL is installed, we want `python36-gobject` to be installed automatically, which is currently not the case.
We now differentiate between RHEL7 and RHEL8 when automatically installing PyGObject. Under RHEL7 we install `python36-gobject` from EPEL and under RHEL8 we install `python3-gobject` from the official repositories. The change has been tested under both of these distributions and seems to work as expected using both means of installing the GTK dependencies (`syscheck.sh` and `tl-setup`).
The following tests have all been done with server build 2075: * The bug on SLES 15 when the window got wider when installing Python LDAP dependencies was tested, and the window no longer changes size. * Package 'python36-gobject' is indeed installed on RHEL 7, both via syscheck.sh and tl-setup. * I have tested that PyGObject is installed by tl-setup (i.e. text mode) with an answer file on the following distributions: - SLES 12 - SLES 15 - Ubuntu 18.04 - Ubuntu 20.04 - RHEL 7 - RHEL 8 - CentOS 8 - Fedora 33 Everything works as expected, closing!
Based on above comment, does it mean the server is close to release? On the download page, I only see the nightly build for the client, but not the server.
Depends on what one might consider "close". :) We hope to release it during the summer. So somewhere June/July. There are still a bunch of things that need to be completed before then.
Note that nightly builds of the ThinLinc Server are not publicly available.
Reopening due to a regression: Running `sudo /opt/thinlinc/sbin/tl-setup` and pressing Ctrl-C should result in a dialog telling you how to restart tl-setup. After the conversion to PyGObject we are instead faced with an error dialog saying "Internal error" - "The ThinLincServer Installation Wizard will now terminate." Running `sudo ./install-server` and pressing Ctrl-C should result in the installer exiting without any error messages. After the conversion to PyGObject we are instead faced with the same dialog as described above.
After further investigation, our excepthook (responsible for producing the above "Internal error" dialog) is fired once the stack has been unwound to the root of the GTK main loop after a KeyboardInterrupt is raised. Not unwinding the whole stack is somewhat reasonable since it makes it possible for the main loop to recover and continue spinning after an exception. At first glance, KeyboardInterrupts seem to be an exception to what is described above [1]. However, this does not to apply when installing a custom python handler for SIGINT, which we do to avoid an issue where a program launched with sudo receives two SIGINTs when given single Ctrl-C [2]. A couple of possible approaches: - Remove the double SIGINT workaround altogether. In [3] it is mentioned that this behaviour will be fixed in sudo. It may be the case that all recent distributions have a sufficiently new sudo installed. - When running with GTK, sudorelaunch starts the current application as a subprocess. The double SIGINT workaround is installed for both of these processes. A possible approach would be to install a similar workaround signal handler for the parent process such that the child (running the GTK main loop) will not need the double SIGINT workaround and thus not require a SIGINT handler to be installed. - Do something hacky where we invoke the main loop such that we can continue the exception propagation past the GTK main loop. References: - [1] https://github.com/GNOME/pygobject/commit/a321f6e9d8f5b8e779892eab4ce759b60ff98e39, https://github.com/GNOME/pygobject/commit/58f677bfaa0f117465a9e2146c5d83768b5a76ac Commits introducing said exception for KeyboardInterrupt. - [2] https://www.cendio.com/bugzilla/show_bug.cgi?id=4191 - Bug discussing the use of of the double SIGINT workaround. - [3] https://bugs.python.org/issue14476 - Description of the issue forcing us to use a double SIGINT workaround.
I found the sudo commit fixing the double SIGINT issue: https://github.com/sudo-project/sudo/commit/2fd77381a1ea06071a439b78e342925f2c5b8fd3 These changes shipped with sudo 1.8.4, meaning that the double SIGINT workaround is no longer needed for SLES12 (sudo 1.8.27) nor RHEL7 (sudo 1.8.23). Thus, removing the workaround seems like the most reasonable way forward.
Debian 9 also has a sufficiently new sudo (1.8.19p1)
Sadly, the changes in [1] in comment 146 shipped with PyGObject 3.27, meaning that older distributions such as SLES12, RHEL7, Ubuntu 16.04 and Debian stretch will still have issues with SIGINTs (see comment 46). As of now, we will not implement a workaround for this since it seems unlikely for those running these aging distributions to use the graphical installer/tl-setup in the first place.
Tested on Fedora 33 and Ubuntu 20.04 with Jenkins server build #2099 and now both the installer and tl-setup behave as they did in 4.12.1 in regards respecting SIGINTs. Please note that bug 7713 is yet to be resolved, and will thus require testing to be performed from a root shell and *not* using our currently broken sudo re-launch mechanism. Also note comment 149 regarding testing on older distributions. Testing is a matter of checking whether we exhibit the same behavior as in 4.12.1 in regards to sending a SIGINT (Ctrl-C) to tl-setup and tlinstaller running in a root shell. Marking as resolved.
Created attachment 983 [details] Link is not displayed as intended The link is not shown correctly. I have tested tl-4.12.1 and then the link is blue and clickable*. To reproduce one might need to manually add code to get an error. As of build 2101 there is a bug in zypperbackend so this will be triggered on SLES. * But the browser is not opened since we try to open the browser as root it seems. I get this output: > Running Firefox as root in a regular user's session is not supported. ($HOME is /home/cendio which is owned by cendio.)
The last issue mentioned in comment 152 was present before moving to PyGObject, see bug 7704.
Markup should now be working again. This only affected the error dialogs in install-server and tl-setup, so that's all that needs to be retested.
The error dialog looks fine now, tested both installer and tl-setup. Tested on SLES 12 with build 2108. Had to manually break the code to get an internal error.
Tested SIGINT in tl-setup as described in comment #151 on Fedora 33 using jenkins build 2108. Everything looks good apart from a separate issue which I have now made a new bug for: bug 7721. Release notes looks good.
On SLES 15 this files is missing after running tl-setup once in text-mode: > /usr/lib64/python3.6/site-packages/gi/overrides/Gtk.py This makes the graphical tl-setup fail when needing to be relaunched as sudo. > ERROR:root:Traceback (most recent call last): > ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 309, in <module> > ERROR:root: i1i1iiII ( ) > ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 217, in i1i1iiII > ERROR:root: sudorelaunch . sudo_question ( oO0 , oO0 ) > ERROR:root: File "/opt/thinlinc/modules/thinlinc/sudorelaunch.py", line 45, in sudo_question > ERROR:root: I1Ii111i1I . format_secondary_text ( "Do you want to try re-launching %s through 'sudo'?" % program ) > ERROR:root:AttributeError: 'MessageDialog' object has no attribute 'format_secondary_text' After some quick investigation a package that provides the required file is 'python3-gobject-Gdk'. We might need to install this instead on SLES?
Tested GUI tl-setup on SLES 12 and SLES 15. We now install the needed packages so we don't get the error in comment 158. On SLES 12 I needed to manually install Python 3 and 'python3-gobject-Gdk' was installed as a dependency. That is why we did not find this on SLES 12.
We overlooked some translation changes here. We now have to manually handle some translations that GTK+ previously sorted out for us. Most of these don't matter as they are only used in tlinstaller and tl-setup, which aren't translated anyway. But there is one part that has regressed, and that are the buttons for EntryDialog. This is used in tl-sso-update-password, which no longer has the proper translations.
Another issue are changes made in r36974 caused the problem described in bug 7702 Comment #61: "Everything works as expected except for an issue where we rely on the GTK3 typelib to be installed as a dependency. The problem here is that the we only depend on the GTK typelib capability without depending on a specific version of said typelib. Thus, for sufficiently new SUSE releases, we get the GTK4 typelib instead of the GTK3 typelib. We should therefore explicitly install `typelib-1_0-Gtk-3_0` on SUSE distros (along with our other GTK dependencies)."
Translations are now properly updated. Verified by manually recreating tl-misc.pot and checking that "_OK" and "_Cancel" are now included.
(In reply to Niko Lehto from comment #163) > Another issue are changes made in r36974 caused the problem described in bug > 7702 Comment #61: > > "Everything works as expected except for an issue where we rely on the GTK3 > typelib to be installed as a dependency. The problem here is that the we > only depend on the GTK typelib capability without depending on a specific > version of said typelib. Thus, for sufficiently new SUSE releases, we get > the GTK4 typelib instead of the GTK3 typelib. We should therefore explicitly > install `typelib-1_0-Gtk-3_0` on SUSE distros (along with our other GTK > dependencies)." I can verify that this has been fixed now. Tested both when installed by syscheck and tl-setup on SLES 15. On SLES 12 all packages are installed as a dependency to Python 3.
(In reply to Pierre Ossman from comment #168) > Translations are now properly updated. Verified by manually recreating > tl-misc.pot and checking that "_OK" and "_Cancel" are now included. Tested to create the pot file for the translations, and can confirm that the tags "_OK" and "_Cancel" are present. Also tested to add swedish translations for the tags, and the translations can be seen when using "tl-sso-update-password".
Accidentally reopened the bug. It is resolved, and can be closed now that the testing is done.
We try to install "python3-gobject" on CentOS 7, this package doesn't exist even if you have EPEL installed. The package exists on CentOS 8. In commit r36838 on this bug we added a workaround for this problem on RHEL 7. The issue is that the workaround doesn't help on CentOS 7 due to how our distribution detection works. Since CentOS 7 is such a popular distro we should fix this.
If you manually installed "python36-gobject" on CentOS 7 and then proceed with tl-setup the same issue existed for python3-ldap/python36-ldap. Both issues should have been fixed now, some testing remains.
Things look good. Tester should verify that: * the proper python*-gobject and python*-ldap packages are installed * that distribution version is printed in tlsetup.log * that no unexpected side effects of distribution version occurs We need to verify that it still works on RHEL 7 and 8, CentOS 8, non RHEL-family distros, and also that things now work on CentOS 7.
I tested the fix on CentOS 8 Stream and CentOS 7 by the way.
I was able to reproduce the issue with build #2243. Tested using server bundle build #2244. - Build #2244 systemtype.py reports identical data as in build #2243 on all distributions except for CentOS where a version number is now given - [X] CentOS 7 - [X] CentOS 8 - [X] RHEL7 - [X] RHEL8 - [X] Mint 19 - [X] SLES15 - [X] Ubuntu 20 - [X] Debian 10 - python3-gobject and python3-ldap installed by tl-setup - [X] CentOS 7 - [X] CentOS 8
Correction of comment 179: > Build #2244 systemtype.py reports identical data as in build #2243 on all distributions except for CentOS where a version number is now given was supposed to say > Build #2244 systemtype.py reports identical data as in build #2243 on all distributions except for CentOS *and Mint 19* where a version number is now given
