Building on EL9 family

[Alan Brown]

As a fyi: 21.1.3 tarball doesn't build on Rhel9/clang using the existing SPEC files and instructions

The most obvious issue is that clang treats all warnings as errors and the MD5 code is deprecated, however it still falls over after this is overridden

The build-test script building from the current git (merge 1180) mostly succeeds

[Alan Brown]

using the system-tests script as a template on 21.1.3, the following change is all that's needed

- cmake -Dpostgresql=yes -Dsystemtest_db_user=$USER -Dtraymonitor=yes ../bareos
+make -Dpostgresql=yes -Dsystemtest_db_user=$USER -Dtraymonitor=yes -DCMAKE_CXX_FLAGS="-Wno-error=deprecated-declarations" ../bareos

Make test then works with the following error

The following tests FAILED:
        286 - system:py3plug-fd-local-fileset (Failed)

Which is the same as I get for systemtests on pre-22.x testing 

Webui tests are not building due to missing chromelib

I'll dig a little more and work out what changes are needed for the SPEC file

[Alan Brown]

Things aren't as smooth as I was hoping by dropping back to an EL8 system and building on that

In short, the build scripts are not correctly detecting they're running on RHEL and then attempt to set bogus requires, plus miss important things (like redhat-lsb)

This is occurring because {?rhel_version} isn't valid in rpmbuild unless you're generating it dynamically - and the specfile does not do that

There's some discussion about this on stackoverflow but the short version is that you can't (and shouldn't) build for specific RHEL minor versions  - https://stackoverflow.com/questions/55131772/how-to-check-for-redhat-rhel-minor-version-in-rpm-spec-file

Centos is so closely tied into RHEL these days that I doubt the centos_version macro is working correctly either

Should I post the diff here or pastebin?

[Alan Brown]

Extra EL8 requires "so far"

====

EPEL!

gtest-devel
mariadb-devel.x86_64
json-c-devel
libxml2-devel
nfs4-acl-tools (unsure on this one)
gdb
mtx
mt-st
s3cmd
php
pamtester
pam_script
python3-selenium.noarch
chromedriver
binutils-devel
libgit2-devel
libbsd-devel

(vixdisklib requires vmware, which isn't part of the RH/EPEL set)

====

in order to use the postgresql.org repos (PGDG) instead of RH ones

for whichever PG version you have installed:

alternatives --install /usr/pgsql pgsql /usr/pgsql-14/ 20
alternatives --install /usr/include/pgsql pgsql-include /usr/pgsql/include 20

(This can probably be dealt with via scripting)

====

NB: gtest is NOT being detected correctly. I'm still trying to figure out why, as it is OK using the buildtest scripts

====

spec diff

91c91
< %if 0%{?rhel_version} > 0 && 0%{?rhel_version} < 500
---
> %if 0%{?rhel} > 0 && 0%{?rhel} < 5
100c100
< %if 0%{?centos_version} == 505 || 0%{?rhel_version} == 505
---
> %if 0%{?centos_version} == 505 || 0%{?rhel} == 5
111c111
< %if 0%{?rhel_version} >= 700 || 0%{?centos_version} >= 700
---
> %if 0%{?rhel} >= 7 || 0%{?centos_version} >= 700
117c117
< %if 0%{?rhel_version} >= 700 && !0%{?centos_version}
---
> %if 0%{?rhel} >= 7 && !0%{?centos_version}
126c126
< %if 0%{?centos_version} == 700 || 0%{?rhel_version} == 700
---
> %if 0%{?centos_version} == 700 || 0%{?rhel} == 7
209c209
< %if 0%{?centos_version} > 700 || 0%{?rhel_version} > 700 || 0%{?fedora} >= 29
---
> %if 0%{?centos_version} > 700 || 0%{?rhel} > 7 || 0%{?fedora} >= 29
220c220
< %if 0%{?centos_version} >= 800 || 0%{?rhel_version} >= 800 || 0%{?fedora} >= 31
---
> %if 0%{?centos_version} >= 800 || 0%{?rhel} >= 8 || 0%{?fedora} >= 31
255c255
< %if 0%{?rhel_version} || 0%{?centos_version} || 0%{?fedora_version}
---
> %if 0%{?rhel} || 0%{?centos_version} || 0%{?fedora_version}
260c260
< %if 0%{?rhel_version}   && 0%{?rhel_version} <= 600
---
> %if 0%{?rhel}   && 0%{?rhel} <= 6

272c272
< %if 0%{?rhel_version} >= 600 || 0%{?centos_version} >= 600 || 0%{?fedora_version} >= 14
---
> %if 0%{?rhel} >= 6 || 0%{?centos_version} >= 600 || 0%{?fedora_version} >= 14
287c287
< %if 0%{?rhel_version} >= 700 || 0%{?centos_version} >= 700 || 0%{?fedora_version} >= 16 || 0%{?suse_version} >= 1110
---
> %if 0%{?rhel} >= 7 || 0%{?centos_version} >= 700 || 0%{?fedora_version} >= 16 || 0%{?suse_version} >= 1110
913c913
< %if 0%{?centos_version} == 700 || 0%{?rhel_version} == 700
---
> %if 0%{?centos_version} == 700 || 0%{?rhel} == 7

[Jörg Steffens]

Hello Alan,

are you aware, that we already integrated support for RHLE9 into
bareos/master and the bareos/bareos-21 branch? But as you already found
out, this happened after bareos-21.1.3 has been released. However, it
will be part of 21.1.4.
Packages are available at
https://download.bareos.org/bareos/experimental/nightly/EL_9/ (master)
We switched to build the packages only once for all RHEL 8/9 platforms,
but perform automatic tests for a number of platforms.
The EL8 this is currently:
EL@Rocky-8-x86_64
EL@Alma-8-x86_64
EL@Oracle-8-x86_64
EL@Stream-8-x86_64

About the rhel_version macro:
we used https://openbuildservice.org/ (https://build.opensuse.org/) in
the past, where the macros have been set like this.
You can work around this by passing define to rpmbuild:

rpmbuild --define='rhel_version=800' ...

(to speed up the build process, we created our own build environment
based on docker images).

We probably would also accept a PR changing rhel_version to rhel, ...
against master.

I hope, this helps.

Regards,
Jörg

On 28.06.22 at 11:00 wrote Alan Brown:

> --
> You received this message because you are subscribed to the Google
> Groups "bareos-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> bareos-devel...@googlegroups.com
> <mailto:bareos-devel...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bareos-devel/b81c201b-220c-4b0f-8efa-06cf9ba5ad33n%40googlegroups.com
> <https://groups.google.com/d/msgid/bareos-devel/b81c201b-220c-4b0f-8efa-06cf9ba5ad33n%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
Jörg Steffens joerg.s...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221 630693-91
http://www.bareos.com Fax: +49 221 630693-10

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer:
S. Dühr, M. Außendorf, Jörg Steffens, P. Storz

[Alan Brown]

Another issue: GNU find ordering. Max/min depth arguments need to be before type/name

===

+ find /home/bareos/rpmbuild/BUILDROOT/bareos-21.1.3-1_mssl.x86_64//usr/lib64/bareos -type l -name 'libbareos*.so' -maxdepth 1 -exec rm '{}' ';'
find: warning: you have specified the -maxdepth option after a non-option argument -type, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it).  Please specify options before other arguments
===

bareos.spec diff

1095c1095
< find %{buildroot}/%{library_dir} -type l -name "libbareos*.so" -maxdepth 1 -exec rm {} \;
---
> find %{buildroot}/%{library_dir} -maxdepth 1 -type l -name "libbareos*.so" -exec rm {} \;

[Alan Brown]

I saw the nightly, but these are listed as 22-pre. If it's 21.1.4 then I'll use this as a basis for builds, although at this stage I'm trying to get a stable 21.1.3 build on my RHEL8.6 system (management will not allow nightly builds in production environments) before moving to back EL9 as I've discovered i also need to support lin_tape and IBM haven't released EL9 drivers for that yet 

(As far as library/drive suppliers are concerned, the only "officially supported" driver on Linux for LTO is lin_tape, not the crufty old "st" driver that dates back 40 years and has a lot of baggage in it)

Regarding the use of rhel_version/rhel, I'll bet that opensuse have either made an assumption based on past (non EL) versions and not validated it or not been checking to see if Redhat have changed things as time goes by - I ran into this a few times in the past with their older code and getting them to acknowledge that "documentation doesn't always reflect real life" can be "difficult" at times

The issue at the moment is that the 21.1.3 tarball flat out "doesn't build" on RHEL 8.6 without substantial extra work on a "minimum system" install (which should be regarded as a start point for calculating requires and dependencies)

I've got it to the point where the RPMs are now building (still lots of test failures, but I think they are a result of database and database bareos user not being pre-created), so can crosscheck with the bareos-21 branch git code

What would you need for a PR?

[Jörg Steffens]

Hello Alan

On 28.06.22 at 12:46 wrote Alan Brown:

> I saw the nightly, but these are listed as 22-pre. If it's 21.1.4 then
> I'll use this as a basis for builds, although at this stage I'm trying
> to get a stable 21.1.3 build on my RHEL8.6 system (management will not
> allow nightly builds in production environments) before moving to back
> EL9 as I've discovered i also need to support lin_tape and IBM haven't
> released EL9 drivers for that yet 

Yes, https://download.bareos.org/bareos/experimental/nightly/EL_9/ is
based on the master branch in github.

Subscription users have also access to
https://download.bareos.com/bareos/testing/CD/bareos-21/EL_9/x86_64/
This contains current builds from the bareos-21 branch. So it contains
currently bareos-21.1.4~pre39.d00b15611-79.el9.x86_64.rpm

> What would you need for a PR?

Well, a PR should improve things and should be pass all our building and
testing process. Replacing the RPM macros might be a candidate for it,
but we accept Pull-Requests only against master.

Regards,
Jörg

> <https://openbuildservice.org/> (https://build.opensuse.org/
> <https://build.opensuse.org/>) in

> > in order to use the postgresql.org <http://postgresql.org> repos

> <https://groups.google.com/d/msgid/bareos-devel/b81c201b-220c-4b0f-8efa-06cf9ba5ad33n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/bareos-devel/b81c201b-220c-4b0f-8efa-06cf9ba5ad33n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
>
> --
> Jörg Steffens joerg.s...@bareos.com
> Bareos GmbH & Co. KG Phone: +49 221 630693-91

> <tel:+49%20221%2063069391>
> http://www.bareos.com <http://www.bareos.com> Fax: +49 221 630693-10
> <tel:+49%20221%2063069310>

>
> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
> Komplementär: Bareos Verwaltungs-GmbH
> Geschäftsführer:
> S. Dühr, M. Außendorf, Jörg Steffens, P. Storz
>

> --
> You received this message because you are subscribed to the Google
> Groups "bareos-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> bareos-devel...@googlegroups.com
> <mailto:bareos-devel...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bareos-devel/31918625-b329-4f4d-9634-b0feb92ef4b4n%40googlegroups.com
> <https://groups.google.com/d/msgid/bareos-devel/31918625-b329-4f4d-9634-b0feb92ef4b4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Andreas Rogge]

Am 28.06.22 um 12:46 schrieb Alan Brown:

> (As far as library/drive suppliers are concerned, the only "officially
> supported" driver on Linux for LTO is lin_tape, not the crufty old "st"
> driver that dates back 40 years and has a lot of baggage in it)

Wether or not what the suppliers say is right or not, the lin_tape
driver has issues of its own and is known not to work with Bareos.

Best Regards,
Andreas

--
Andreas Rogge andrea...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH

Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz