RPM package

[marcosfrm]

Will the RPM package revive? We could port the recent DEB work to it.

[kbernhagen]

I would like, if it's easy.

I'm interested in Asahi Linux, which is currently Arch, but will be Fedora soon.

[marcosfrm]

First I need to solve this:

scons: Building targets ...
build_function(["fah_client-8.2.3-1.x86_64.rpm"], [])
scons: *** [fah_client-8.2.3-1.x86_64.rpm] build/install/rpm/build: No such file or directory
scons: building terminated because of errors.

It is probably here:
https://github.com/CauldronDevelopmentLLC/cbang/blob/master/config/rpm/__init__.py#L42

I suck at Python...

[kbernhagen]

The v7 rpm/build was just

%strip ${RPM_BUILD_ROOT}/usr/bin/*

[marcosfrm]

Well, CentOS 7 is a problem because its GCC (4.8.5) does not support -std=c++14 :

g++ -o build/boost/libs/iostreams/src/bzip2.o -c -std=c++14 -fsigned-char -ffunction-sections -fdata-sections -O3 -funroll-loops -fPIC -DNDEBUG -D_REENTRANT -DUSING_CBANG -Iinclude -Isrc -Isrc/boost src/boost/libs/iostreams/src/bzip2.cpp
g++: error: unrecognized command line option ‘-std=c++14’
scons: *** [build/boost/libs/iostreams/src/bzip2.o] Error 1
scons: building terminated because of errors.

There is https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/ , but honestly I think it does not worth the effort. CentOS Stream 8 is a better choice.

[marcosfrm]

First, for python3-scons and libstdc++-static:

CentOS Stream 8 - PowerTools

dnf config-manager --set-enabled powertools

CentOS Stream 9 - EPEL
https://docs.fedoraproject.org/en-US/epel/#_centos_stream_9

dnf config-manager --set-enabled crb
dnf -y install epel-release epel-next-release

Build:

dnf -y install git python3-scons gcc-c++ libstdc++-static openssl-devel systemd-devel rpm-build systemd-rpm-macros

git clone https://github.com/CauldronDevelopmentLLC/cbang.git
git clone https://github.com/FoldingAtHome/fah-client-bastet.git
export CBANG_HOME=$PWD/cbang
scons-3 -C cbang
scons-3 -C fah-client-bastet
scons-3 -C fah-client-bastet package

[marcosfrm]

When bulding the RPM in RHEL 8 and clones, OpenSSL 1.1.1 is used. rpmbuild adds necessary requirements:

$ rpm -q --requires fah-client
...
libcrypto.so.1.1()(64bit)
libcrypto.so.1.1(OPENSSL_1_1_0)(64bit)
libcrypto.so.1.1(OPENSSL_1_1_1)(64bit)
...
libssl.so.1.1()(64bit)
libssl.so.1.1(OPENSSL_1_1_0)(64bit)
...

which dnf will satisfy, installing compat-openssl11 (RHEL 9 and clones) or openssl1.1 (Fedora 36+) as dependency. The problem is that openssl1.1 has been deprecated in Fedora and will be removed in the near future (https://fedoraproject.org/wiki/Changes/RemoveOpensslCompat). RHEL 10 will follow it.

Hence, perhaps, CentOS Stream 9 is a better choice at this point.

[kbernhagen]

Is this really a problem? OpenSSL is statically linked in client.

[kbernhagen]

The build machine should have openssl 3.0 static libs installed.

That is what is done on macOS.

[marcosfrm]

I was considering distro supplied packages only. With the switch to OpenSSL 3.0 in Fedora 36 (and RHEL 9), openssl-static does not exist anymore:

https://bugzilla.redhat.com/show_bug.cgi?id=2139333

But sure, manually compiling OpenSSL in the build machine does the trick, although for such core library, universally available on Linux, linking the system one may be desirable.

[kbernhagen]

Hmm. Not possible on macOS, which has switched to LibreSSL.

Can the installers make openssl 3 a dependency to be auto installed if needed?

[marcosfrm]

Can the installers make openssl 3 a dependency to be auto installed if needed?

With RPM no problem, since rpmbuild automatically adds versioned dependency on libraries the binary depends on. And OpenSSL 1.1 compatibility package is available in RHEL 9 and Fedora 36-39 (not in future 40+).

DEB on the other hand, in the way we package it, does not do that. Manually adding libssl1.1 (Debian 10 and 11) or libssl3 (Debian 12+) dependency should suffice. By the way, it should depend on libsystemd0 when compiled with it (for correctness only, as the library is required by systemd itself). Debian 12 does not appear to have any libssl1.1 compatible package at all. Keeping a package built in Debian 10/11 working in version 12 will be problematic if linking OpenSSL dynamically.

[marcosfrm]

In light of OpenSSL 1.1.1 deprecation in Red Hat world (no more compat 1.1.1 packages in future releases), one way to link system OpenSSL 3.0 on CentOS Stream 8 is using EPEL packages (see https://docs.fedoraproject.org/en-US/epel/):

sudo dnf -y install epel-release epel-next-release
sudo dnf -y install openssl3-devel

export OPENSSL_INCLUDE=/usr/include/openssl3 OPENSSL_LIBPATH=/usr/lib64/openssl3

...compile...

Resulting RPM requirements:

...
libcrypto.so.3()(64bit)
libcrypto.so.3(OPENSSL_3.0.0)(64bit)
...
libssl.so.3()(64bit)
libssl.so.3(OPENSSL_3.0.0)(64bit)
...

It will work on Fedora 36+ and on RHEL 9+. dnf will refuse to install it on RHEL 8 since nothing provides libcrypto.so.3 and libssl.so.3 on a pristine installation:

Error: 
 Problem: conflicting requests
  - nothing provides libcrypto.so.3()(64bit) needed by fah-client-8.3.0-1.x86_64 from @commandline
  - nothing provides libcrypto.so.3(OPENSSL_3.0.0)(64bit) needed by fah-client-8.3.0-1.x86_64 from @commandline
  - nothing provides libssl.so.3()(64bit) needed by fah-client-8.3.0-1.x86_64 from @commandline
  - nothing provides libssl.so.3(OPENSSL_3.0.0)(64bit) needed by fah-client-8.3.0-1.x86_64 from @commandline
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Once the EPEL repository is enabled, dnf will happily install it:

Dependencies resolved.
================================================================
 Package         Arch     Version          Repository      Size
================================================================
Installing:
 fah-client      x86_64   8.3.0-1          @commandline   2.0 M
Installing dependencies:
 openssl3-libs   x86_64   3.0.7-5.el8.1    epel           2.5 M

Transaction Summary
================================================================
Install  2 Packages

Total size: 4.5 M
Total download size: 2.5 M
Installed size: 12 M
Is this ok [y/N]:

An eventual official RPM documentation could simply say "On RHEL 8 and clones, EPEL repository is required" or so.

[marcosfrm]

I was considering distro supplied packages only. With the switch to OpenSSL 3.0 in Fedora 36 (and RHEL 9), openssl-static does not exist anymore:

https://bugzilla.redhat.com/show_bug.cgi?id=2139333

Correction: RHEL dropped openssl-static earlier, in version 8.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index#removed-packages_changes-to-packages

[marcosfrm]

https://foldingforum.org/viewtopic.php?t=41152

scons package produces an almost functional RPM on (open)SUSE. cbang prints

WARNING: Unrecognized POSIX distribution , trying to determine package type from filesystem

but will work anyway if rpm-build is installed. Just a matter of adding some os-release IDs there.

Two things are wrong:

• Requires(pre) has shadow-utils. It is just shadow on SUSE. On Fedora 32+ and RHEL 9+, shadow-utils provides shadow (see https://src.fedoraproject.org/rpms/shadow-utils/c/9f643a301165a0b1bb1fcb7b9c425809d5791a2f), but this change did not reach RHEL 8. Until we get rid of version 8, RPM boolean dependencies do the trick: (shadow-utils or shadow). They are supported since RPM 4.13. SUSE 15 and RHEL 8 have 4.14. Note: not supported on SLES and SLED 12 (paid versions only), which are still on RPM 4.11.

• Recent SUSE does not have any compatibility with polkit's pkla format, needed by Debian (thanks Debian!!!). If somehow we could install the JavaScript based rule only in the RPM (see Add polkit rule to allow sleep inhibition on Linux #199 (comment)), it would work (polkit package name is equal). Any ideas? I come up with RPM: use new polkit format, adapt for SUSE #220.