Comment 1 Pierre Ossman 2014-10-21 16:45:48 CEST

Ubuntu are doing a survey to see when they can drop support:

https://bryanquigley.com/crazy-ideas/still-running-32-bit-ubuntu

Comment 2 Pierre Ossman 2014-10-28 14:49:14 CET

The just released SLE 12 has also dropped 32-bit support.

Comment 3 Pierre Ossman 2019-01-22 10:08:54 CET

Ubuntu dropped 32-bit support in 17.10. Some of the community spins still retain it though, so it seems you can get a 32-bit Ubuntu with some effort. It is most likely not as well maintained anymore though.

Comment 4 Pierre Ossman 2021-06-15 09:58:14 CEST

Fedora dropped 32-bit support in Fedora 31, and RHEL dropped support in RHEL 7.

This is now starting to become a problem as we can't really test a 32-bit server anymore.

Comment 5 Samuel Mannehed 2021-11-08 15:01:01 CET

Things we should remove from the server bundle:

* all _i386.debs and all _i686.rpms (except for the one below)
* ./sources/tlstunnel-linkkit-i686.tar.gz
* ./packages/thinlinc-tlmisc-libs32_4.13.0post-2331_i386.deb
  - we should keep the other two tlmisc-libs32 packages

Things that seem to be 32-bit specific in the spec-files and the Makefiles:

* search for "i[36]86" gives a nice overview
* CFLAGS
* perhaps the __strip-hack in the spec-files?
* extra flags to configure
* should lib64 directory be hardcoded?
* remember to check for unused variables after cleanup 


Things we need to investigate:

* cenbuild
* CMakeToolchainFile
* --with-int10 for Xvnc's configure
* jenkins configuration
* documentation
* installer & tl-setup
* systemtype.py
* tests for pkginst module
* are there any relevant hits when searching for "x86_64"?

Things we need to decide how to handle:

* how tlmisc should be built and packaged
* shall i386 still be the "base architecture"?

Comment 6 William Sjöblom 2021-11-09 14:22:41 CET

Jenkins no longer tries to run the server tests on i386. Thus, we are now free to stop producing i386 packages for all server-related targets in the top-level Makefile.

Comment 9 Linn 2021-11-09 14:33:30 CET

Tested installing the server on Debian 10 (i386), and with our changes the installation gives an error message instead of starting.

Also verified that server still can be correctly installed on a Fedora 34 machine.

Comment 13 William Sjöblom 2021-11-10 13:24:04 CET

I have rolled back the Jenkins changes mentioned in comment 6 since we still want to run our tests on the 32-bit compatibility libraries in tlmisc-libs32.

Additionally, the top-level make targets no longer produce any 32-bit packages. I have tested building server-bundle and installing it on Fedora 34 and Ubuntu 18.04 (both x86_64) which works like a charm.

Comment 18 William Sjöblom 2021-11-12 10:07:40 CET

Regarding the change of "base" architecture in comment 5, I have
decided to keep `i386' as the base architecture. Still some
`cbrun'-calls in the top-level Makefile have been changed to `x86_64'.

• The server open sources tarballs will be built using `x86_64' instead
  of `i386' since these targets require its corresponding binary tarball
  to be built. The tlstunnel linkkit also get the same treatment.
• All server `noarch' packages are will also be built using `x86_64'
  since they share many build tooling dependencies to their non-`noarch'
  siblings (that are only build for the `x86_64' platform).

Apart from the above exceptions, the use of `i386' as the base
architecture remains unchanged.

Comment 29 Linn 2021-11-15 09:41:23 CET

The 32-bit tlmisc package has now been removed, but we need to keep tlmisc-libs32 to support 32-bit applications. 

We have split the build of tlmisc-libs from tlmisc. This was done since we previously used part of the 32-bit tlmisc package to create tlmisc-libs32.


For testing, we have done the following:

* Checked that the resulting tlmisc, tlmisc-libs and tlmisc-libs32 rpms have the same dependencies as before.
> rpm -qpR <package>
Also checked with rpm -ql that they contain the same things as before, with the exception of the 64-bit package that contains more files than before. This is because the projects we moved to the libs packages contained more things than just libs, and these things are only in the 64-bit libs package. 

* Tested installing and upgrading tlmisc-libs, tlmics-libs32 and tlmisc on both Fedora 34 and Ubuntu 20.04. 

* Since two of the files we moved into the tlmisc-libs package are conf-files, we also tested upgrading this package with changed content in the conf-files. We changed both the old, installed conf and the new to-be-installed conf, and verified that it was handled correctly.

* Also tested that we were able to run a 32-bit application correctly on the server. This was tested on Ubuntu 18.04 with tlclient 32-bit installed on the server. We tested the smartcard redirection.

Comment 30 Pierre Ossman 2021-11-15 09:54:15 CET

I've looked through the source tree and I can't find anything we've missed. I looked through the hits for "i.86" and "32.*bit".

Comment 32 William Sjöblom 2021-11-15 10:31:30 CET

The changes regarding base architecture (mentioned in comment 18) have
now been committed. Together with these changes, I mapped out which
dependencies were needed to build the new standalone tlmisc-libs package
and packaged these in a separate cenbuild metapackage called
`cendio-build-server-lib-deps'. When installing
`cendio-build-serverdeps-x86_64', `cendio-build-lib-deps' will be
installed in both the `x86_64' and `i386' varieties such that we can
still build `tlmisc-libs32' for the `x86_64' platform.

These changes are pretty binary in nature and thus, a successful server
build should be a sufficient test (along with a review of the changes).
I have built the server with these changes locally without any issues.

Comment 35 Linn 2021-11-16 08:46:18 CET

The server now builds correctly in Jenkins after fixing the debug symbols for tlmisc-libs and tlmisc-libs32. Marking as resolved.

Comment 36 Pierre Ossman 2021-11-16 12:22:15 CET

> * Remove everything that is only used for the 32-bit server.
>  - Both in ctc and in cenbuild

I cannot find anything that should be removed in either ctc or cenbuild. Also checked "rebuild --obsolete" and nothing was reported.

> * Keep support for 32-bit applications on 64-bit servers, for example pcsctun.

Tested running our 32-bit on a 64-bit Ubuntu 20.04. It was able to read the smart card via pcsctun.

> * Attempting to install ThinLinc on a 32-bit system should result in some kind of user facing notification.

Tested Debian 10. In both text and GUI mode you get:

> Unsupported architecture
> Your architecture (i686) is not supported by ThinLinc.
> Please refer to the documentation for a list of supported platforms.

Comment 37 Pierre Ossman 2021-11-16 14:32:51 CET

I've checked all the commits and everything looks good there.

The packages included in the server-bundle look correctly. With the exception of libs32, they are all either x86_64 or noarch. We also have deb version of every rpm. All files are roughly the same size as 4.13.0, except tlmisc-libs, which has grown slightly because of the extra files in it, and tl-misc which has a larger ssh-keyscan (bug 7764).

The server-debug bundle also looks okay, with the only 32-bit package remaining being the libs32 one.

I can see that unit tests are still run for both i386 and x86_64, same thing for the installed files test (result files in build/).

Sources also looks complete and roughly the same size as been for. The 32-bit linkkit for tlstunnel is gone.

Comment 38 William Sjöblom 2021-11-16 14:40:11 CET

I've checked the debug packages for `tlmisc-libs(32)?' and all [1] debug info are properly installed and perfectly loadable by gdb. 

[1] Except for nss-passwdaliases that, as far as I can tell, has never had any proper debug info.

Comment 39 William Sjöblom 2021-11-16 14:52:26 CET

All libraries `tlmisc-libs(32)?' are also properly stripped of all debug symbols.

Comment 40 William Sjöblom 2021-11-16 16:19:54 CET

I have now taken a look at the documentation/release notes, both of which look fine.

I have also compared the combined file listings of the `tlmisc(-libs(32)?)?' RPMs for ThinLinc 4.13.0 and the latest Jenkins build (#2345) and they are identical.

Marking as closed.