#2135 Issue closed
: SLES11 and RHEL/CentOS 5 snapshot builds fail on OBS¶
Labels: fixed / solved / done
, blocker
gdha opened issue at 2019-05-06 09:00:¶
-
ReaR version ("/usr/sbin/rear -V"): 2.4-snapshots
-
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): SLES 11 (SP1-SP4) and RHEL/CentOS 5
-
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): i585 and x86_64
-
Description of the issue (ideally so that others can reproduce it): on openSUSE Build Service the rear snapshots fail to build and break on the following:
[ 27s] [1m== Installing documentation ==[0;0m
[ 27s] make -C doc install
[ 27s] make[1]: Entering directory `/usr/src/packages/BUILD/rear-2.4-git.0.3930248.unknown/doc'
[ 27s] install -Dp -m0644 rear.8 %{buildroot}/usr/share/man/man8/rear.8
[ 27s] make[1]: Leaving directory `/usr/src/packages/BUILD/rear-2.4-git.0.3930248.unknown/doc'
[ 27s] sed -i -e 's,/etc,/etc,' \
[ 27s] -e 's,/usr/sbin,/usr/sbin,' \
[ 27s] -e 's,/usr/share,/usr/share,' \
[ 27s] -e 's,/usr/share/doc/packages,/usr/share/doc,' \
[ 27s] %{buildroot}/usr/share/man/man8/rear.8
[ 27s] sed: can't read %{buildroot}/usr/share/man/man8/rear.8: No such file or directory
[ 27s] make: *** [install-doc] Error 2
[ 27s] error: Bad exit status from /var/tmp/rpm-tmp.4728 (%install)
-
Workaround, if any: on SLES 12 and higher there are no problems on that level.
-
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files): see https://build.opensuse.org/project/show/Archiving:Backup:Rear:Snapshot
jsmeix commented at 2019-05-06 10:02:¶
Currently only a blind guess:
Perhaps this is because of the disabled BuildRoot since
https://github.com/rear/rear/commit/2819c071681a19fc3382aa84bfaf1654508a64aa
jsmeix commented at 2019-05-06 11:39:¶
My blind guess was incomplete:
Actually both changes in
https://github.com/rear/rear/commit/2819c071681a19fc3382aa84bfaf1654508a64aa
need to be reverted to make it build again on SLES11 RHEL 5 CentOS 5
With disabled
#%defattr(-, root, root, 0755)
build fails with those messages in the build log
... checking for files with abuild user/group
abuild abuild /etc/cron.d/rear
abuild abuild /etc/rear
.
.
.
abuild abuild /var/lib/rear
please fix your filelist (e.g. add defattr)
jsmeix commented at 2019-05-06 12:03:¶
See
https://build.opensuse.org/package/show/home:jsmeix:branches:Archiving:Backup:Rear:Snapshot/rear
therein in particular the rear.spec file
https://build.opensuse.org/package/view_file/home:jsmeix:branches:Archiving:Backup:Rear:Snapshot/rear/rear.spec?expand=1
where I also removed /etc/cron.d/rear/ and its related things
cf.
https://github.com/rear/rear/issues/1892
gdha commented at 2019-05-07 09:42:¶
@jsmeix I can confirm that the OBS builds succeeded successfully last night.
jsmeix commented at 2019-05-07 09:49:¶
With
https://github.com/rear/rear/pull/2136
merged
this issue is fixed.
pcahyna commented at 2021-06-30 17:12:¶
@jsmeix this can be reverted according to https://relax-and-recover.org/rear-user-guide/releasenotes/rear26.html#supported_and_unsupported_operating_systems , right?
jsmeix commented at 2021-07-01 06:01:¶
What Linux distributions we build ReaR packages for and
what Linux distributions we declare as "supported" by ReaR
are related but different things.
In general we build ReaR packages for more Linux distributions
than what we declare as "supported" Linux distributions.
I listed some examples at the end.
I can be discussed if it makes sense to build and provide ReaR
packages
for Linux distributions that are not also declared as "supported"
i.e. for Linux distributions where we at ReaR upstream "dropped official
support"
according to our current ReaR upstream release notes - also avialable
here
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L2524
but the actual source of our release notes is there
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-6.md
I think the release notes describe (somewhat indirectly)
why we build and provide ReaR packages also for
Linux distributions where we "dropped official support".
See the release notes starting at
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L2552
that read (excerpts):
ReaR-2.6 may still work for SLES 11 and openSUSE Leap 42.x or even earlier
openSUSE versions but it is no longer sufficiently well tested there so
arbitrary regressions could appear.
ReaR 2.6, ReaR-2.5, and ReaR-2.4 (and probably also some earlier versions)
are known to no longer work reasonably well for the following Linux based
operating systems:
o RHEL 5 (and probably also CentOS 5): See issue #1766
o SLES 9 and 10: See issue #1842
If you require support for unsupported Linux operating systems you must
acquire a ReaR support contract.
Neither
https://github.com/rear/rear/issues/1766
nor
https://github.com/rear/rear/issues/1842
look hopeless to make latest ReaR work even on older Linux
distributions
in particular for specific use cases where specific workarounds could
help.
Building and providing ReaR packages also for
Linux distributions where we "dropped official support"
it intended to help users with older Linux distributions
who may need latest ReaR bugfixes or features and
who can help themselves to adapt newest ReaR to make it
still work on older Linux distributions as they need it
in their specific environments.
And if they cannot can help themselves to adapt ReaR
to make it work as they need it in their specific environment
those ReaR upstream authors who offer ReaR support contracts
could (hopefully) more easily make some money.
Bottom line:
The idea behind why we build ReaR packages also for
Linux distributions where we "dropped official support" is
to make latest ReaR "just available" for older Linux distributions
so that users who need latest ReaR for older Linux distributions
can more easily try out how far it works for their specific use cases.
A side note:
I know that a noticable part of users prefer to have usual packages
(e.g. RPM packages) instead of what I described in the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
But I don't know about their reasons behind.
Perhaps it is because the upstream GitHub master code is a moving
target?
But one could always checkout a specific git commit to stay at a fixed
state.
Perhaps it is mostly because they are used to deal with e.g. RPM
packages,
perhaps in particular in restricted business/managed environments?
Examples where we build ReaR packages for more Linux distributions
than what we declare as "supported" Linux distributions:
https://build.opensuse.org/project/show/Archiving:Backup:Rear:Snapshot
builds currently successfully for
('osc' is a command line tool to access the openSUSE Build Service)
# osc results Archiving:Backup:Rear:Snapshot rear | grep succeeded | cut -d ' ' -f1 | sort -u
CentOS_7
CentOS_8
CentOS_CentOS-5
CentOS_CentOS-6
Debian_10
Debian_7.0
Debian_8.0
Debian_9.0
Debian_Testing
Debian_Unstable
Fedora_30
Fedora_31
Fedora_32
Fedora_33
Fedora_Rawhide
openSUSE_13.1
openSUSE_13.2
openSUSE_Factory
openSUSE_Factory_PowerPC
openSUSE_Leap_15.0
openSUSE_Leap_15.1
openSUSE_Leap_15.2
openSUSE_Leap_15.3
openSUSE_Leap_42.1
openSUSE_Leap_42.2
openSUSE_Leap_42.3
openSUSE_Tumbleweed
PowerKVM_3.1
RedHat_RHEL-5
RedHat_RHEL-6
RHEL_7
ScientificLinux_6
ScientificLinux_7
SLE_10_SDK
SLE_11
SLE_11_SP1
SLE_11_SP2
SLE_11_SP3
SLE_11_SP4
SLE_12
SLE_12_SP1
SLE_12_SP2
SLE_12_SP3
SLE_12_SP4
SLE_12_SP5
SLE_15
SLE_15_SP1
SLE_15_SP2
SLE_15_SP3
xUbuntu_12.04
xUbuntu_14.04
xUbuntu_16.04
xUbuntu_16.10
xUbuntu_17.04
xUbuntu_17.10
xUbuntu_18.04
xUbuntu_18.10
xUbuntu_19.04
xUbuntu_19.10
xUbuntu_20.04
xUbuntu_20.10
https://build.opensuse.org/package/show/Archiving:Backup:Rear/rear-2.6
builds currently successfully for
# osc results Archiving:Backup:Rear rear-2.6 | grep succeeded | cut -d ' ' -f1 | sort -u
CentOS_7
CentOS_8
CentOS_CentOS-5
CentOS_CentOS-6
Debian_10
Debian_7.0
Debian_8.0
Debian_9.0
Fedora_30
Fedora_32
Fedora_33
openSUSE_Factory
openSUSE_Factory_PowerPC
openSUSE_Leap_15.2
openSUSE_Leap_15.2_PowerPC
openSUSE_Leap_15.3
openSUSE_Tumbleweed
PowerKVM_3.1
RedHat_RHEL-5
RedHat_RHEL-6
RHEL_7
ScientificLinux_6
ScientificLinux_7
SLE_11
SLE_11_SP4
SLE_12
SLE_12_SP5
SLE_15
SLE_15_SP2
SLE_15_SP3
xUbuntu_12.04
xUbuntu_14.04
xUbuntu_16.04
xUbuntu_16.10
xUbuntu_17.04
xUbuntu_17.10
xUbuntu_18.04
xUbuntu_18.10
xUbuntu_19.04
xUbuntu_19.10
xUbuntu_20.04
xUbuntu_20.10
[Export of Github issue for rear/rear.]