Comment 1 Karl Mikaelsson 2015-02-18 11:20:24 CET

(In reply to comment #0)
> This means that the eLux packages gains a dependency on
> "rpmlib(PayloadFilesHavePrefix) >= V4.0-1", and a "./" prefix for all file
> names in the package. The rpmlib dependency is incompatible with (at least)
> Elias 7.5.0, which will complain that nothing provides the rpmlib(..) feature.

In normal cases, our rpm2elux script will catch the rpmlib dependency and refuse to convert the RPM. In my testing, I had this check temporarily removed to see how Elias/eLux handled.

Comment 2 Pierre Ossman 2015-02-24 11:53:40 CET

We'll start by trying to influence upstream to bring this feature back.

Comment 3 Peter Åstrand 2016-01-07 16:25:54 CET

Upstream report, with a nice ticket number:

http://rpm.org/ticket/900

Comment 4 Karl Mikaelsson 2016-01-21 12:32:23 CET

Reassigning for discussion on next development meeting.

Comment 5 Peter Åstrand 2016-04-04 11:59:17 CEST

Patch available now, but forgot to handle PayloadFilesHavePrefix dependency.

Comment 7 Peter Åstrand 2016-04-05 08:43:48 CEST

(In reply to comment #5)
> Patch available now, but forgot to handle PayloadFilesHavePrefix dependency.

This has been fixed now. RPM trunk (51348f5acee4ef8e2fa420fdab02a35af4cc8e76) seems to work correctly for building the eLux RPM. Eventually, when this fix is included in a release, we should upgrade.

Comment 8 Alexander Zeijlon 2024-03-11 12:33:42 CET

We'll take a look at upgrading rpm to a newer version now, since we need it for Bug 2960 and Bug 7809.

Comment 9 Alexander Zeijlon 2024-03-11 12:48:20 CET

As of version 4.19.x [1], rpm has started using CMake as a build system instead of autoconf. And while it of course would be nice to jump directly to the latest release, we will opt for packaging version 4.18.2 [2] which is the last release that is built with autoconf. At this point in time, we want to be able to continue with the bugs mentioned in comment 8 and not risk having to handle issues related to the change of build system in our rpm spec file.

[1] The latest release is 4.19.1 at the moment.
[2] Version 4.18.2 was released November 2023.

There are a few updated and new dependencies we need to look at:

* (New) Lua >= 5.3
* (New) Debugedit >= 5.0
* (Upd) Sqlite >= 3.22

Comment 10 Alexander Zeijlon 2024-03-11 13:08:17 CET

(In reply to Alexander Zeijlon from Bug 2960 comment #20)
> Turns out that we are missing Lua as a requirement for rpm in cenbuild.
> 
> I looked at the lua source, and it is quite minimal, and can be built with
> any ANSI C compiler.
> 
> Sadly, it is not using Autoconf or CMake which means that we need to do a
> more manual build configuration, especially if we want to be able to include
> it in non-linux archs in cenbuild.
> 
> Lets look at only building for linux arch for now since these are the only
> ones that require the rpm package.
(In reply to Alexander Zeijlon from Bug 2960 comment #22)
> I also found that the default prefix path /usr/local/ is hardcoded at one
> place in the source code, even if the Makefile suggests that it is OK to set
> it to something else while building.
> 
> Just to be sure, I added a patch that sets that path to /usr/ in the source
> code, which happens to be the prefix we set when we build packages,
> independent of arch for native packages.
> 
> This is maybe not the most robust way of handling it, and we will likely
> have to revisit this issue in the future if we need to build lua for our
> target archs.
Bringing these comments over from Bug 2960 since they directly relate to building rpm.

I have investigated this a bit further and e.g. Fedora injects their own autoconf for Lua as a part of their build procedure. We will do the same thing since this opens up for building Lua for the target archs in the future in a simple way if we would need it.

This also ensures that we build the library liblua.so. The original make file only built a liblua.a for static linking, and we want to be able to dynamically link libraries.

Comment 11 Alexander Zeijlon 2024-03-11 16:31:41 CET

I built rpm 4.18.2 together with its dependencies:
* Lua 5.4.6
* Sqlite 3.45.1
* Debugedit 5.0

Then tested installing and running both ThinLinc client and server on:

* RHEL7, RHEL8 and RHEL9
* Ubuntu 20.04 and Ubuntu 22.04 (.deb files built with rpm2debpkg)

Seems to work just as before the upgrade.

Comment 12 Alexander Zeijlon 2024-03-11 16:42:24 CET

I'm not sure how relevant the comments above from 2016 still are. We should look into those before closing.

Comment 21 Linn 2024-03-18 11:22:51 CET

When updating rpm version, we ran into the issue that was solved in bug 8064. It was triggered during the client build, and when looking at build variables some of them were not correctly set:

Ok:
> OPENSSL_CFLAGS:          -I/usr/arm-none-linux-gnueabi/sys-root/usr/include 
> OPENSSL_LIBS:            -L/usr/arm-none-linux-gnueabi/sys-root/usr/lib -lcrypto
> ...
> GIO2_CFLAGS:             -pthread -I/usr/arm-none-linux-gnueabi/sys-root/usr/include/glib-X -I/usr/arm-none-linux-gnueabi/sys-root/usr/lib/glib-X/include
Crash:
> OPENSSL_CFLAGS:          
> OPENSSL_LIBS:            -lcrypto 
> ...
> GIO2_CFLAGS:             -pthread -I/usr/include/glib-X -I/usr/lib/glib-X/include
We see that some variables are missing, and that some variables use non-toolchain paths, which is not ok.

Comment 22 Linn 2024-03-18 13:01:25 CET

This issue is caused by rpm exporting PKG_CONFIG_PATH during %build, which was added by Red Hat to get around an issue when building packages in multilib environments [1], later merged in rpm upstream [2].

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=212522
[2]: https://github.com/rpm-software-management/rpm/commit/aa8979f4

The main issue is the Red Hat bug was that pkg-config was using the native system's %_libdir (as it was set when pkg-config was built), e.g. /usr/lib64/ on an x86_64 system. Instead, Red Hat actually need pkg-config to look at the %_libdir set at runtime. E.g., "setarch i386" changes the libdir path to /usr/lib/.

The solution Red Hat implemented to get around this is issue was by always exporting PKG_CONFIG_PATH at runtime:
> %___build_pre_env \
> ...
> PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\
> export PKG_CONFIG_PATH

Our toolchains work with the default behaviour for pkg-config, so we want to make sure that PKG_CONFIG_PATH is not set.

In bug 8064, we did this by simply unsetting PKG_CONFIG_PATH before the configure script is run during build (which calls pkg-config).

Comment 25 Samuel Mannehed 2024-03-18 17:13:30 CET

When upgrading the cenbuild package for rpm, we missed adding at least one "BuildRequires". As part of the configure step, the build complains with:

> checking for libgcrypt-config... no
> configure: error: libgcrypt not found
On machines which already have cendio-build-libgcrypt, things work well. However, we want things to be reliable on any system. That means we need to have an exhaustive list of all build requirements.

We used Fedora's list as a guideline [1]. To verify their list, we cross-examined it with configure.ac and the INSTALL documentation ([2]).

[1] https://src.fedoraproject.org/rpms/rpm/blob/f38/f/rpm.spec
[2] https://github.com/rpm-software-management/rpm/blob/master/INSTALL

When constructing the new list of build requirements to test with, it differed in a number of ways from Fedora's. Out of the unconditional BuildRequires, we don't think we have to include the following:

* redhat-rpm-config  - required by rpmbuild, which we run outside cenbuild
* systemd-rpm-macros - required by rpmbuild, which we run outside cenbuild
* libacl             - configure.ac shows that this is not required by default
* libcap             - configure.ac shows that this is not required by default

Out of Fedora's conditional BuildRequires, we don't think we have to include the following:

* fakechroot     - only used by tests, which we don't use
* xz             - optional according to INSTALL [2]
* libzstd        - configure.ac shows that this is not required by default
* libselinux     - configure.ac shows that this is not required by default
* dbus           - configure.ac shows that this is not required by default
* audit          - configure.ac shows that this is not required by default
* ima-evm-utils  - configure.ac shows that this is not required by default
* fsverity-utils - configure.ac shows that this is not required by default

We added a few requirements and have now started a rebuild with "--no-repo" and are awaiting the results.

Comment 27 Samuel Mannehed 2024-03-19 12:12:25 CET

(In reply to Samuel Mannehed from comment #25)
> We added a few requirements and have now started a rebuild with "--no-repo"
> and are awaiting the results.

This was a bit overkill, we can still use the other packages available from our repo. After ~16 hours we stopped the full rebuild and instead simply uninstalled cendio-build-everything followed by a rebuild of only cendio-build-rpm. Things worked well and libgcrypt was found.

Comment 29 Linn 2024-03-19 16:06:15 CET

When upgrading rpm, we noticed that some of our debug files changed names from X-debug-Y to X-debuginfo-Y. This is due to a rename made in RPM v. 4.11.0 [1]:
> Debug information sub-packages renamed to -debuginfo to match common distro practises
[1]: https://rpm.org/wiki/Releases/4.11.0

Comment 31 Linn 2024-03-19 17:20:26 CET

I did some testing to check that our rpm-packages built with rpm v. 4.18 still can be installed properly.

I tested by installing the server and client on Ubuntu 22.04, as well as checking our backwards compatibility by installing the same packages on CentOS 6 (rpm v. 4.8.0). 

The packages could be installed without any issue on both platforms.

Comment 34 Linn 2024-03-21 09:25:05 CET

The issue with cross compiling to build our arm rpm (see comment 21 and comment 22) has been reported upstream to rpm:
https://github.com/rpm-software-management/rpm/issues/2987

Comment 35 Samuel Mannehed 2024-03-21 09:39:30 CET

It doesn't seem like there are any requirements from the old rpm version that we now can remove.

Comment 36 Samuel Mannehed 2024-03-21 16:45:28 CET

We noticed that our new rpm version no longer shipped with man pages. This is because rpm made them conditional to if `pandoc` was found. We decided to skip including man pages.

Comment 38 Samuel Mannehed 2024-03-21 16:53:19 CET

With that, moving to RESOLVED:

 * The requirements of the cendio-build-rpm package has been reviewed.
 * All comments on the commits have been handled.
 * All important information has been documented here in bugzilla.
 * ThinLinc packages built using cendio-build-rpm have been tested.

Comment 40 Alexander Zeijlon 2024-03-25 10:33:19 CET

We had missed that there is a build requirement on GnuGP when building rpm. This was easily missed when building locally, where I happened to already have GnuPG (gpg) installed.

If rpm's configure script does not find gpg2 or gpg, it will default to /usr/bin/gpg2 and continue building anyway. This meant that we had a situation where rpm expected to find gpg2 when rpmsign is called, which then would error since it does not exist.

As an intermediate workaround, I added symlinks from /usr/bin/gpg2 to /usr/bin/gpg. Fedora/RHEL does the same thing for compatibility. But this is not really what we want to do. We want rpm to look for the correct binary that is provided by the GnuPG package.

The packages for rpm and GnuPG have now been built to be in sync with each other such that rpm expects to find /usr/bin/gpg, which means that it requires GnuPG as an installation requirement.

Comment 41 Linn 2024-03-25 16:46:30 CET

Tested the acceptance critera:

MUST:

  ✅ After upgrading rpm to a newer version, it should still be possible to build our rpm packages in cenbuild.
> Our server- and client packages (both regular and debug ones) can still be built
> after updating cendio-build-rpm to the new version.
  ✅ It should still be possible to install packages built rpm packages on our supported rpm platforms.
> Yes. I tested installing the server rpm on SLES 15 and Fedora 39, and I could
> install the rpm without issues (however, on Fedora 39 I did run into bug 8325).
> Also tested backwards compatability on CentOS 6, and the packages could install
> fine. [*]
  ✅ The tool rpm2debpkg should still produce valid and working deb-packages that can be installed on our supported Debian based platforms.
> Tested installing the server on Ubuntu 20.04, no issues.

[*] Note however that tl-setup were not able to run due to this error (also seen in comment 31 but not noted there):
> Traceback (most recent call last):
>   File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 15, in <module>
>     import readline
> ModuleNotFoundError: No module named 'readline'

Comment 42 Linn 2024-03-25 16:47:08 CET

Also went through the old comments on this bug from 2015-2016. They were all regarding eLux, and a note of these possible issues has been made on bug 7041.

Looked through the commits as well, looks good. Only thing left is to wait for the Jenkins build to go through and this can be closed.

Comment 43 Linn 2024-03-26 08:58:26 CET

The Jenkins build for cenbuild has finished and passed. Closing.