Bug 7508 - No PyGTK on Ubuntu 20.04
Summary: No PyGTK on Ubuntu 20.04
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: William Sjöblom
Keywords: frifl_tester, linma_tester, nikle_tester, relnotes, samuel_tester, wilsj_tester
Depends on:
Blocks: 7688 7692 7702
  Show dependency treegraph
Reported: 2020-06-01 13:58 CEST by Pierre Ossman
Modified: 2021-08-13 15:56 CEST (History)
8 users (show)

See Also:
Acceptance Criteria:

Link is not displayed as intended (20.87 KB, image/png)
2021-05-27 14:13 CEST, Frida

Description Pierre Ossman cendio 2020-06-01 13:58:59 CEST
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.
Comment 3 Pierre Ossman cendio 2020-06-01 14:01:20 CEST
Also note bug 7492 which makes this much worse.
Comment 4 Samuel Mannehed cendio 2020-06-02 13:49:01 CEST
This problem does not affect all new distros, Fedora 32 for example has this package:

Comment 5 Samuel Mannehed cendio 2020-06-02 13:56:04 CEST
A platform specific note has been added:


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.
Comment 6 Pierre Ossman cendio 2020-06-29 09:40:30 CEST
Release is out and PSN has been updated.
Comment 7 Jens Maus 2020-08-05 16:59:56 CEST
I also hit this issue after updating to Ubuntu 20.04 but found the following solution:


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!
Comment 10 Feng Ye 2021-04-13 03:03:03 CEST
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.
Comment 11 Steve Moulton 2021-04-13 15:20:57 CEST
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
Comment 12 Samuel Mannehed cendio 2021-04-14 10:31:53 CEST
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.
Comment 13 Jens Maus 2021-04-14 10:44:01 CEST
@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!
Comment 14 Samuel Mannehed cendio 2021-04-19 13:04:58 CEST
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):


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.
Comment 15 Samuel Mannehed cendio 2021-04-19 13:15:10 CEST
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).
Comment 16 Samuel Mannehed cendio 2021-04-19 13:31:56 CEST
The GTK2 C API is available here, it might be useful when converting from Pygtk2 to PyGObject/GTK3:


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:


Once built, could we host it internally somehow? It doesn't seem to be available anywhere online.
Comment 17 Samuel Mannehed cendio 2021-04-19 13:48:47 CEST
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!).
Comment 46 Pierre Ossman cendio 2021-04-29 09:53:14 CEST
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.
Comment 47 Pierre Ossman cendio 2021-04-29 09:58:03 CEST
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.
Comment 57 William Sjöblom cendio 2021-05-03 13:23:04 CEST
`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".
Comment 123 William Sjöblom cendio 2021-05-11 08:43:52 CEST
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
Comment 124 William Sjöblom cendio 2021-05-11 09:59:06 CEST
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.
Comment 125 William Sjöblom cendio 2021-05-12 11:02:01 CEST
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.
Comment 128 William Sjöblom cendio 2021-05-12 12:37:19 CEST
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`
Comment 129 Linn cendio 2021-05-12 14:36:43 CEST
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.
Comment 132 Samuel Mannehed cendio 2021-05-14 16:10:44 CEST
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.
Comment 134 William Sjöblom cendio 2021-05-17 09:44:35 CEST
The issue described in comment 129 has now been corrected.
Comment 135 Pierre Ossman cendio 2021-05-17 09:58:41 CEST
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.
Comment 136 William Sjöblom cendio 2021-05-17 13:31:42 CEST
The issue described in comment 135 was found to be a side-effect of the fix for bug #7671. Marking as resolved once again.
Comment 137 William Sjöblom cendio 2021-05-17 17:05:01 CEST
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.
Comment 139 William Sjöblom cendio 2021-05-18 09:19:23 CEST
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`).
Comment 140 Linn cendio 2021-05-20 14:16:52 CEST
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!
Comment 141 Feng Ye 2021-05-20 14:37:25 CEST
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.
Comment 142 Pierre Ossman cendio 2021-05-20 14:41:01 CEST
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.
Comment 143 Samuel Mannehed cendio 2021-05-20 14:42:28 CEST
Note that nightly builds of the ThinLinc Server are not publicly available.
Comment 145 William Sjöblom cendio 2021-05-24 10:34:42 CEST
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

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.
Comment 146 William Sjöblom cendio 2021-05-24 15:53:56 CEST
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

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.

- [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.
Comment 147 William Sjöblom cendio 2021-05-24 17:24:06 CEST
I found the sudo commit fixing the double SIGINT issue:

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
Comment 148 William Sjöblom cendio 2021-05-25 09:07:20 CEST
Debian 9 also has a sufficiently new sudo (1.8.19p1)
Comment 149 William Sjöblom cendio 2021-05-25 15:45:11 CEST
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.
Comment 151 William Sjöblom cendio 2021-05-25 17:07:33 CEST
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.
Comment 152 Frida cendio 2021-05-27 14:13:13 CEST
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.)
Comment 153 William Sjöblom cendio 2021-05-27 20:02:12 CEST
The last issue mentioned in comment 152 was present before moving to PyGObject, see bug 7704.
Comment 155 Pierre Ossman cendio 2021-05-28 12:27:18 CEST
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.
Comment 156 Frida cendio 2021-05-31 12:45:05 CEST
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.
Comment 157 Niko Lehto cendio 2021-06-02 14:40:16 CEST
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.
Comment 158 Frida cendio 2021-06-03 16:34:08 CEST
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?
Comment 161 Frida cendio 2021-06-08 10:01:15 CEST
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.
Comment 162 Pierre Ossman cendio 2021-06-15 14:42:33 CEST
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.
Comment 163 Niko Lehto cendio 2021-06-15 15:08:03 CEST
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)."
Comment 168 Pierre Ossman cendio 2021-06-16 10:37:36 CEST
Translations are now properly updated. Verified by manually recreating tl-misc.pot and checking that "_OK" and "_Cancel" are now included.
Comment 169 Frida cendio 2021-06-16 13:25:12 CEST
(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.
Comment 170 Linn cendio 2021-06-16 15:34:46 CEST
(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".
Comment 171 Linn cendio 2021-06-16 15:43:54 CEST
Accidentally reopened the bug. It is resolved, and can be closed now that the testing is done.
Comment 172 Samuel Mannehed cendio 2021-08-06 10:53:59 CEST
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.
Comment 176 Samuel Mannehed cendio 2021-08-09 10:21:13 CEST
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.
Comment 177 Samuel Mannehed cendio 2021-08-10 10:49:58 CEST
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.
Comment 178 Samuel Mannehed cendio 2021-08-10 16:31:37 CEST
I tested the fix on CentOS 8 Stream and CentOS 7 by the way.
Comment 179 William Sjöblom cendio 2021-08-11 08:57:53 CEST
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
Comment 180 William Sjöblom cendio 2021-08-13 13:12:03 CEST
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

Note You need to log in before you can comment on or make changes to this bug.