#3238 Issue `closed`: RFC: Preparations towards release of ReaR 2.8¶

Labels: fixed / solved / done, ReaR Project

gdha opened issue at 2024-06-05 09:42:¶

Rear v2.7 was released in July 2022 (more than 2 years ago), therefore,
the time has come to start on the preparations of a new release 2.8.

The ReaR release process is described at
https://github.com/rear/rear/wiki/Release-process

We could add a "blocker" label on the issues we think that should/must
be included in the 2.8 release.

Other issues that can wait must be relabeled with a "ReaR 3.0" or later or "ReaR 999 (future)" label.

When you tested the pre-2.8 release make a note in our WIKI page:
https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8

jsmeix commented at 2024-06-05 10:42:¶

@rear/contributors
because we already had some discussions about ReaR 3.0:
What about releasing what is currently labeled ReaR 2.8
as ReaR 3.0?

schlomo commented at 2024-06-05 11:10:¶

I'm all in favour!!!

jsmeix commented at 2024-06-17 07:23:¶

As usual I will make the release notes for ReaR 2.8
i.e. a new
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md
from which a new
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
will be made as described at

Convert the release notes from the ReaR web pages into a simple text file

in
https://github.com/rear/rear/wiki/Release-process#preparation

Making the release notes is currently blocked by
https://github.com/rear/rear/issues/3302
"Distribute rear-release-notes.txt under a more permissive license"
because it depends on its outcome whether or not
I could make the release notes for ReaR 2.8
based on the release notes for ReaR 2.7
or if I need to make the release notes for ReaR 2.8
anew from scratch under "GPL v3 or later".

jsmeix commented at 2024-11-13 07:26:¶

@rear/contributors
should I change this issue into
"Preparations towards release of ReaR 2.8"
or should I create a new separated issue for this?

schlomo commented at 2024-11-13 09:05:¶

Let's just change it. I always took it for "prep for next release" and we now decided to name the next release 2.8

jsmeix commented at 2024-11-18 16:01:¶

Via
https://github.com/rear/rear.github.com/commit/24251c3f092fd2ceca9082def5a052a72326eaad
I committed a new release-notes-2-8.md from scratch
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md
to avoid in particular licensing issues with
https://github.com/rear/rear/issues/3302

I carefully omitted any text of the currently
still open (i.e. not yet answered) licensing issues
of https://github.com/rear/rear/issues/3302
https://github.com/rear/rear/issues/3302#issuecomment-2468171038
https://github.com/rear/rear/issues/3302#issuecomment-2468214053
https://github.com/rear/rear/issues/3302#issuecomment-2468149845

The sections

New features, bigger enhancements, and possibly backward incompatible changes

and

Details (mostly in chronological order - newest topmost)

will now (i.e. in the next days) be filled up by me step by step
with the the latest release notes for ReaR 2.8
(and only for ReaR 2.8).

jsmeix commented at 2024-11-19 15:12:¶

It went faster than expected to fill up the "Details" section,
see the current
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md

The "Details" entries are basically "copy&paste" excerpts
of what the command

git log --format="%ae %H %ad%n%s :%n%b%n" --graph | fmt -w 160 -u -t | less

shows in a local git clone.

According to what that command shows
some of those entries became rather long texts.
I do not want (and I do not have the time) to analyze
each longer text, if this or that part could be omitted
or re-written in a more concise form.

jsmeix commented at 2024-11-22 08:43:¶

@rear/contributors
please have a look at
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md
if this or that needs to be improved or if you spot typos.

In my personal opinion I don't mind when there are long texts.
In case of doubt or in case of no time to improve texts
I prefer more and explanatory information where people
(users and developers) need more time to read them
over terse snippets where others (in particular our users)
may not understand what something actually is about.

jsmeix commented at 2024-11-22 08:53:¶

The currently remaining open pull requests for ReaR 2.8 are

https://github.com/rear/rear/pull/3171 (blocker)
"Make OS detection from /etc/os-release more robust"

https://github.com/rear/rear/pull/3345 (blocker)
"Make sourcing DUPLY_PROFILE reasonably secure"

https://github.com/rear/rear/pull/3344 (bug)
"Minor os-detection improvements"

@rear/contributors
please have a look at them.
All have a review approval so
provided no objections appear
I would merge them on Monday afternoon.

jsmeix commented at 2024-11-25 12:47:¶

With
https://github.com/rear/rear/pull/3345
https://github.com/rear/rear/pull/3171
https://github.com/rear/rear/pull/3344
merged,
there are currently no open issues or pull requests
for ReaR 2.8 - except this one here.

@rear/contributors
please test (as time permits) current GitHub master code and
when it works for you report what you tested successfully in
https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8
and when something fails then open an issue.

gdha commented at 2024-12-04 08:28:¶

There are currently no outstanding blockers - we are in the freeze period for the upcoming 2 weeks. Only pre-approved changes will be merged (as agreed during our meeting calls).
The release of ReaR v2.8 is planned before 25 December 2024.

jsmeix commented at 2024-12-06 12:45:¶

No open issues with milestone "ReaR 2.8" except this one
and no open pull requests with milestone "ReaR 2.8"
plus added latest git commit messages to "Details" in
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md

So our current GitHub master code is now (I think for the first time)
in a state where we could release that code as ReaR 2.8
as described in
https://github.com/rear/rear/wiki/Release-process
which does not mean it will be released right now as is,
it only means there is no issue or pending pull request
that needs to be solved before the ReaR 2.8 release.

I will be on vacation starting on 21. Dec. 2024
there are two weeks left where I could help
to release ReaR 2.8 before 25 December 2024.

@rear/contributors
I wish you all a relaxed and recovering weekend!

jsmeix commented at 2024-12-10 11:35:¶

The ReaR 2.8 release notes on our web page
looked bad because in the "Details" section
all git commit messages were shown as one single code block
so it was totally incomprehensible in practice.

I had to do unexpectedly much trial and error
until I found out what in the markdown source
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md
I need to do to show each git commit message in a
separated code block:

Only a separated

&nbsp;

line between subsequent markdown fenced code blocks
also makes each separated code block appear
separated on our web page:
https://relax-and-recover.org/documentation/release-notes-2-8

From the current web page I generated
rear-release-notes.txt ASCII file
according to
https://github.com/rear/rear/wiki/Release-process

export LC_ALL=POSIX
export LANG=POSIX
w3m -dump -cols 78 https://relax-and-recover.org/documentation/release-notes-2-8 | iconv -f UTF-8 -t ASCII//TRANSLIT | sed -e 's/^      ? /      - /' > rear-release-notes.txt

which looks good to me so we can still have for ReaR 2.8
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
as an ASCII file.

jsmeix commented at 2024-12-10 11:39:¶

@rear/contributors
please have a look at my current rear-release-notes.txt
for ReaR 2.8 in
https://github.com/rear/rear/issues/3238#issuecomment-2531502357
and if you agree with its content
I would replace our current one for ReaR 2.7
with the new one for ReaR 2.8
which would actually fix
https://github.com/rear/rear/issues/3302
in our ReaR sources.

In the current rear-release-notes.txt
I manually removed the header

Relax-and-Recover

  o Home
  o Features
  o Documentation
  o Downloads
  o Support
  o Development
  o Events

Relax-and-Recover Release Notes

and the footer

If you like Relax-and-Recover please consider sponsorship

I also noticed that there are no URLs for links.
I found
https://stackoverflow.com/questions/41345160/display-link-url-in-markdown
which shows URLs within angle brackets for
"Automatic Links, where the label is the URL".

I use now in our source
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md
plain text for the link label
and URLs within angle brackets like

Relax-and-Recover website: <http://relax-and-recover.org>

GitHub project: <https://github.com/rear>

For older Relax-and-Recover version release notes see the
Relax-and-Recover website release notes: <http://relax-and-recover.org/documentation>

because only this works for our source on GitHub
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-8.md
and also on our web page at relax-and-recover.org
https://relax-and-recover.org/documentation/release-notes-2-8
and also for the generated ASCII rear-release-notes.txt

jsmeix commented at 2024-12-10 12:27:¶

rear-release-notes.txt

jsmeix commented at 2024-12-11 15:19:¶

I cleaned up my rear/rear "jsmeix" branches
https://github.com/rear/rear/branches
i.e. I removed all old/outdated/obsoleted "jsmeix" branches
but I kept which belong to my current "draft" pull requests
which I like to get somehow done (regardles how)
in ReaR 3.0:
https://github.com/rear/rear/pull/3258
"On hold: Implement SourceTrustworthy function"
https://github.com/rear/rear/pull/3203
"On hold: New source_variable_from_file()"
or later:
https://github.com/rear/rear/pull/3166
"WIP: Use the new TextPrefix function"

jsmeix commented at 2024-12-11 16:21:¶

@schlomo @gdha @pcahyna
I would like that you do a thorough proofread of
all the 'git' related things in
https://github.com/rear/rear/wiki/Release-process
and where needed clarify and enhance it
so that the 'git' related descriptions therein
become basically foolproof.

My personal reason for my above request is
that I am not at all a 'git' expert
so when I should do the ReaR 2.8 release
my main fear is that I may accidentally / stupidly
mess up things in our GitHub rear/rear repository.

I would appreciate it if there was a foolproof method
described how to somehow store some kind of "snapshot"
of our GitHub rear/rear repository so that one could
revert the repository to a stored snapshot state
if the repository got messed up.
I think every git commit is such a "snapshot"
so is git reset --hard <commit> THE right way to do it?
But git reset --hard <commit> does it on my local repository
so how could one do it on our GitHub rear/rear repository?

Background information:
In recent years I moved more and more
away from using 'git' on my local workstation
towards using the GitHub web frontend.
This was triggered by the general move away
from using local tools towards using web-frontends
for various things (e-mail, chat, whatnot...)
to do my work in recent years - yes, I know about
the "Service as a Software Substitute" problem
https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

My personal reason is that I am not much interested in 'git'
because it is just a tool for source code management
but I am not really interested in management.
Instead my actual interest is creating (software)
so I like to keep management things out of my way ;-)

jsmeix commented at 2024-12-18 12:09:¶

My current plan what I will do for the ReaR 2.8 release:

I will basically follow what is described
in the section "Preparation" in
https://github.com/rear/rear/wiki/Release-process#preparation
but I would perfer to do it in a more clean way if possible
which means in particular that I would like to
keep separated issues separated (KSIS derived from KISS)
so I propose the following procedure which tries to keep
steps that change files our rear/rear GitHub repository
separated from other steps.

(A: Preparation steps that change files)

Today afternoon:

I will do the step

Finalize commits/versions

and the two steps

Test packaging (RPM, DEB, …)

Create OBS build

I assume only "Finalize commits/versions"
is meant to change source files in the master branch
of our rear/rear GitHub repository.

I assume "Test packaging (RPM, DEB, …)" and "Create OBS build"
do not and should not change any source file in any branch
of our rear/rear GitHub repository.
I will check that.

(B: Some time so that latest changes can be checked)

Have some time so that @rear/contributors
could have a look at the latest state of
our rear/rear GitHub repository
which is meant to be then released "as is".

(C: The actual release)

Tomorrow before noon:

Only the actual release of the source files "as is"
in the master branch in our rear/rear GitHub repository.

The actual release is not meant to change any source file
in any branch of our rear/rear GitHub repository.

Accordingly - as far as I understand it - the actual release consists
of the following steps to release 'ReaR 2.8' in this case here:

(1)
Make a pristine local git clone
of our GitHub rear/rear repository
and change into it:

git clone https://github.com/rear/rear.git

mv rear rear-release

cd rear-release

(2)
Add an empty commit (no source file gets changed)
in the master branch to denote when the release happened:

git commit -S --allow-empty -m 'ReaR 2.8 release'

(3)
Tag the current state (HEAD) in the master branch:

git tag -s -a rear-2.8 -m "Rear release 2.8"
git tag -s -a 2.8 -m "Rear release 2.8"

(4)
Push the changes in the local git clone to our GitHub rear/rear repository:

git push --tags

@rear/contributors
please have a look here and tell me if there is something wrong
with my plan what to do for the ReaR 2.8 release.

pcahyna commented at 2024-12-18 12:19:¶

@jsmeix I will push my changes to release notes soon.

pcahyna commented at 2024-12-18 12:20:¶

https://github.com/rear/rear.github.com/pull/23

jsmeix commented at 2024-12-18 13:08:¶

My results for "Test packaging (RPM, DEB, …)"
on my homeoffice workstation:

Only RPM:

In a local clone of our current GitHub master code
(i.e. without updated version in usr/sbin/rear and
in packaging/rpm/rear.spec so it is still version 2.7)

# git clone https://github.com/rear/rear.git

# mv rear rear-test-packaging-rpm

# cd rear-test-packaging-rpm

# make rpm OFFICIAL=1 && echo OK || echo FAILED
...
OK

# git ls-files . --ignored --exclude-standard --others
dist/rear-2.7-1.src.rpm
dist/rear-2.7-1.x86_64.rpm
dist/rear-2.7.tar.gz

# git ls-files . --exclude-standard --others
[no output]

# ls -lhdtr /var/tmp/build-rear-2.7/*
-rw-r--r-- 1 root root 992K Dec 18 13:52 /var/tmp/build-rear-2.7/rear-2.7.tar.gz
drwxr-xr-x 3 root root 4.0K Dec 18 13:52 /var/tmp/build-rear-2.7/rear-2.7
-rw-r--r-- 1 root root 6.6K Dec 18 13:52 /var/tmp/build-rear-2.7/rear.spec
drwxr-xr-x 8 root root 4.0K Dec 18 13:52 /var/tmp/build-rear-2.7/rpmbuild

# diff -s dist/rear-2.7.tar.gz /var/tmp/build-rear-2.7/rear-2.7.tar.gz
Files dist/rear-2.7.tar.gz and /var/tmp/build-rear-2.7/rear-2.7.tar.gz are identical

I compared what is in /var/tmp/build-rear-2.7/rear-2.7.tar.gz
with what is in my GitHub master code clone and
I found that

usr/share/rear/skel/default/root/.vimrc

is not in /var/tmp/build-rear-2.7/rear-2.7.tar.gz
but this file is needed because

# git log -p --follow usr/share/rear/skel/default/root/.vimrc

commit 700727b53855d551c0620c46a839755894b26eb3
Author: Johannes Meixner <jsmeix@suse.com>
Date:   Mon Feb 19 13:08:44 2024 +0100

    Fix issue 3151: missing .vimrc and overhauled 130_create_dotfiles.sh (#3154)

    Create an empty
    usr/share/rear/skel/default/root/.vimrc
    to fix https://github.com/rear/rear/issues/3151
...

# rpmlint -vi dist/rear-2.7-1.x86_64.rpm
If 'rpmlint' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf rpmlint

I give up here because I won't change my
homeoffice workstation into a RPM build system
because I don't build RPMs on my workstation
(I use only the SUSE and openSUSE build services).

I don't think that building RPMs directly belongs
to the actual tasks to release a new version of ReaR.

I think building RPMs and testing that it works
(which includes testing the built RPMs)
is a separarted task like any other functionality
in ReaR that needs to be maintained and tested.

jsmeix commented at 2024-12-18 13:12:¶

My results for "Test packaging (RPM, DEB, …)"
on my homeoffice workstation:

Only DEB:

In a local clone of our current GitHub master code
(i.e. without updated version in usr/sbin/rear and
in packaging/rpm/rear.spec so it is still version 2.7)

# git clone https://github.com/rear/rear.git

# mv rear rear-test-packaging-deb

# cd rear-test-packaging-deb

# make deb OFFICIAL=1 && echo OK || echo FAILED
...
bash: dch: command not found
make: *** [Makefile:292: deb] Error 127
FAILED

I give up here because I won't change my
homeoffice workstation into a DEB build system
because I don't build packages on my workstation
(I use only the SUSE and openSUSE build services).

I don't think that building packages directly belongs
to the actual tasks to release a new version of ReaR.

I think building packages and testing that it works
(which includes testing the built packages)
is a separarted task like any other functionality
in ReaR that needs to be maintained and tested.

jsmeix commented at 2024-12-18 13:19:¶

My results for "Test packaging (RPM, DEB, …)"
on my homeoffice workstation:

Only "make dist OFFICIAL=1":

In a local clone of our current GitHub master code
(i.e. without updated version in usr/sbin/rear and
in packaging/rpm/rear.spec so it is still version 2.7)

# git clone https://github.com/rear/rear.git

# mv rear rear-test-packaging-dist

# cd rear-test-packaging-dist/

# make dist OFFICIAL=1 && echo OK || echo FAILED
...
OK

# git ls-files . --ignored --exclude-standard --others
dist/rear-2.7.tar.gz

# git ls-files . --exclude-standard --others
[no output]

Also here (as expected)
usr/share/rear/skel/default/root/.vimrc
is not in dist/rear-2.7.tar.gz
but this file is needed because
https://github.com/rear/rear/issues/3151
cf.
https://github.com/rear/rear/issues/3238#issuecomment-2551280753

schlomo commented at 2024-12-18 13:22:¶

@jsmeix may I suggest that you use tools/run-in-docker, as it uses reliably build environments and doesn't depend on your local setup. For example I can run this even on my Mac:

❯ tools/run-in-docker -a amd64 11 -- make package
Using architecture amd64 instead of default Docker architecture aarch64
********** debian:11                                **********
rm -f dist/*.rpm dist/*.deb dist/*.pkg.*
== Building archive rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 ==
rm -Rf /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28
mkdir -p dist /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28
tar -c --exclude-from=.gitignore --exclude=.gitignore --exclude=".??*" COPYING  doc  etc  MAINTAINERS  Makefile  packaging  README.md  tests  tools  usr | tar -C /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 -x
== Rewriting /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/{packaging/rpm/rear.spec,packaging/debian/rear.dsc,usr/sbin/rear} ==
sed -i \
    -e 's#^\(Source0\?\):.*#\1: rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28.tar.gz#' \
    -e 's#^Version:.*#Version: 2.7#' \
    -e 's#^%define rpmrelease.*#%define rpmrelease .git.5549.7f9b67ea.schlomoprepareforrelease28#' \
    -e 's#^%setup.*#%setup -q -n rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28#' \
    -e 's#^%\(autosetup.*\)#%\1 -n rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28#' \
    /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/packaging/rpm/rear.spec
sed -i \
    -e 's#^Version:.*#Version: 2.7-0git.5549.7f9b67ea.schlomoprepareforrelease28#' \
    /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/packaging/debian/rear.dsc
sed -i \
    -e 's#^readonly VERSION=.*#readonly VERSION=2.7-git.5549.7f9b67ea.schlomoprepareforrelease28#' \
    -e 's#^readonly RELEASE_DATE=.*#readonly RELEASE_DATE="2024-12-17"#' \
    /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/usr/sbin/rear
tar -czf dist/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28.tar.gz -C /var/tmp/build-rear-2.7 rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28
== Building DEB package rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 ==
rm -rf /var/tmp/build-rear-2.7
mkdir -p /var/tmp/build-rear-2.7
tar -C /var/tmp/build-rear-2.7 -xzf dist/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28.tar.gz
cd /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 ; mv packaging/debian/ .
cd /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 ; dch -v 2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 -b -M /var/tmp/build-rear-2.7 package
cd /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 ; debuild -us -uc -i -b --lintian-opts --profile debian
 dpkg-buildpackage -us -uc -ui -i -b
dpkg-buildpackage: info: source package rear
dpkg-buildpackage: info: source version 2.7-git.5549.7f9b67ea.schlomoprepareforrelease28
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by ReaR Team <contact@relax-and-recover.org>
 dpkg-source -i --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
   dh_auto_clean
    make -j4 clean
make[1]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
rm -Rf dist /var/tmp/build-rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28 etc/os.conf etc/site.conf var build-stamp
/usr/bin/make -C doc clean
make[2]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc'
rm -f unconv.8 *.html *.xml
make -C user-guide clean
make[3]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc/user-guide'
rm -f *.html *.svg *.xml
make[3]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc/user-guide'
make[2]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc'
make[1]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
   dh_clean
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
   dh_auto_build
    make -j4
make[1]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
Nothing to build. Use 'make help' for more information.
make[1]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
   dh_auto_test
   create-stamp debian/debhelper-build-stamp
 debian/rules binary
dh binary
   dh_testroot
   dh_prep
   dh_auto_install
    make -j4 install DESTDIR=/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
== Validating scripts and configuration ==
find etc/ usr/share/rear/conf/ -name '*.conf' | xargs -n 1 bash -n
bash -n usr/sbin/rear
find . -name '*.sh' | xargs -n 1 bash -O extglob -O nullglob -n
find usr/share/rear -name '*.sh' | grep -v -E '(lib|skel|conf)' | while read FILE ; do \
    num=$(echo ${FILE##*/} | cut -c1-3); \
    if [[ "$num" = "000" || "$num" = "999" ]] ; then \
        echo "ERROR: script $FILE may not start with $num"; \
        exit 1; \
    else \
        if $( grep '[_[:alpha:]]' <<< $num >/dev/null 2>&1 ) ; then \
            echo "ERROR: script $FILE must start with 3 digits"; \
            exit 1; \
        fi; \
    fi; \
done
== Prepare manual ==
/usr/bin/make -C doc man
make[2]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc'
make[2]: Nothing to be done for 'man'.
make[2]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc'
== Installing configuration ==
install -d -m0700 /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/etc/rear/
install -d -m0700 /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/etc/rear/cert/
[[ ! -e /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/etc/rear/local.conf ]] && \
    install -Dp -m0600 etc/rear/local.conf /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/etc/rear/local.conf
[[ ! -e /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/etc/rear/os.conf && -e etc/rear/os.conf ]] && \
    install -Dp -m0600 etc/rear/os.conf /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/etc/rear/os.conf
make[1]: [Makefile:162: install-config] Error 1 (ignored)
find /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/etc/rear/ -name '.gitignore' -exec rm -rf {} \; &>/dev/null
== Installing binary ==
install -Dp -m0755 usr/sbin/rear /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/sbin/rear
sed -i -e 's,^CONFIG_DIR=.*,CONFIG_DIR="$REAR_DIR_PREFIX/etc/rear",' \
    -e 's,^SHARE_DIR=.*,SHARE_DIR="$REAR_DIR_PREFIX/usr/share/rear",' \
    -e 's,^VAR_DIR=.*,VAR_DIR="$REAR_DIR_PREFIX/var/lib/rear",' \
    -e 's,^LOG_DIR=.*,LOG_DIR="$REAR_DIR_PREFIX/var/log/rear",' \
    /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/sbin/rear
== Installing scripts ==
rm -Rf /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/share/rear
install -d -m0755 /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/share/rear/
cp -a usr/share/rear/. /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/share/rear/
find /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/share/rear/ -name '.gitignore' -exec rm -rf {} \; &>/dev/null
== Installing working directory ==
install -d -m0755 /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/var/lib/rear/
install -d -m0755 /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/var/log/rear/
== Installing documentation ==
/usr/bin/make -C doc install
make[2]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc'
install -Dp -m0644 rear.8 /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/share/man/man8/rear.8
make[2]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/doc'
sed -i -e 's,/etc,/etc,' \
    -e 's,/usr/sbin,/usr/sbin,' \
    -e 's,/usr/share,/usr/share,' \
    -e 's,/usr/share/doc/packages,/usr/share/doc,' \
    /var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28/debian/rear/usr/share/man/man8/rear.8
make[1]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
   dh_installdocs
   dh_installchangelogs
   dh_installman
   dh_lintian
   dh_perl
   dh_link
   dh_strip_nondeterminism
   dh_compress
   debian/rules override_dh_fixperms
make[1]: Entering directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
dh_fixperms --exclude debian/rear/etc/rear
make[1]: Leaving directory '/var/tmp/build-rear-2.7/rear-2.7-git.5549.7f9b67ea.schlomoprepareforrelease28'
   dh_missing
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   dh_gencontrol
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'rear' in '../rear_2.7-git.5549.7f9b67ea.schlomoprepareforrelease28_amd64.deb'.
 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../rear_2.7-git.5549.7f9b67ea.schlomoprepareforrelease28_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source -i --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)
Now running lintian --profile debian rear_2.7-git.5549.7f9b67ea.schlomoprepareforrelease28_amd64.changes ...
warning: running with root privileges is not recommended!
W: rear changes: debian-revision-not-well-formed 2.7-git.5549.7f9b67ea.schlomoprepareforrelease28
W: rear buildinfo: debian-revision-not-well-formed 2.7-git.5549.7f9b67ea.schlomoprepareforrelease28
N: 15 hints overridden (15 warnings); 2 unused overrides
Finished running lintian.
mv /var/tmp/build-rear-2.7/rear_*.deb dist/
********** Copying dist to dist-all/debian-11
** SCRIPT RUN TIME 95 SECONDS **

Please look at the top of the script for instructions for how to prep the Docker images. If you don't give it a target (11 matched debian:11) then it simply builds them all. This is what happens in our automated GitHub Actions workflow for the snapshot builds.

jsmeix commented at 2024-12-18 13:31:¶

My point is that such things
(testing this or that functionality in ReaR)
do not actually belong to the task
to release a new ReaR version.

I never contributed anything to the "make packages"
functionality in ReaR and I don't know how it works.
In particular I do not at all need or use
any "make packages" functionality in ReaR.
Why is it my task to test functionality in ReaR
that I have nothing to do with?

schlomo commented at 2024-12-18 13:34:¶

Ah, I was just reacting to your make deb doesn't work notice and wanted to offer a way how to "make it work" without effort. make package figures out dynamically which package type to build and then calls that, so on Debian it runs make deb and on RHEL/SUSE it runs make rpm.

In any case, my PR branch builds DEBs just fine.

jsmeix commented at 2024-12-18 13:43:¶

By the way FYI

On my homeoffice workstation:

# tools/run-in-docker -a amd64 11 -- make package

tools/run-in-docker: line 145: docker: command not found
...
tools/run-in-docker: line 221: docker: command not found
ERROR: ############### DOCKER RUN FAILED FOR debian:11

For my work my workstation works for me - of course ;-)

I limit the amount of installed software on my workstation
intentionally to what I actually need to do my work
to mimimize the risk of whatever issues.

Things are different for my test VMs
that I run on my workstation as needed.

jsmeix commented at 2024-12-19 09:24:¶

I modified
https://github.com/rear/rear/wiki/Release-process
as far as I meanwhile understand it how it should be done.
In particular:

I moved the "Test packaging" from "Preparation" to "Testing",
see above why I think it belongs to general testing
and not to preparation of the actual release.

I added a section "The actual release" to separate
the preparations for the actual release
from the actual release.

I added comments what parts I skipped (for now) and why,
namely
"Add the list of contributors" (to the release notes)
and
"Create OBS build"
In particular I will do the OBS things after the actual release
as described in the "Distribution" part.

I re-added the step
"Create a new 'stable' branch"
because I find it useful in practice
to also have a git branch for each release
because I assume that not only I but also other users
are more used to deal with git branches
(e.g. the usual 'git checkout branch' command)
than to deal only with git tags.
I think having also a git branch for each release
costs nothing but is useful in practice for users.

pcahyna commented at 2024-12-19 10:07:¶

I re-added the step
"Create a new 'stable' branch"
because I find it useful in practice
to also have a git branch for each release
because I assume that not only I but also other users
are more used to deal with git branches
(e.g. the usual 'git checkout branch' command)
than to deal only with git tags.

git checkout <tag> works just as well.

I think having also a git branch for each release
costs nothing but is useful in practice for users.

It costs confusion to have two objects (branch and tag) with the same name.

If you think it is simpler to have a branch than not to have it, please describe whether git checkout rear-2.5 checks out the branch named rear-2.5 or the tag named rear-2.5.

jsmeix commented at 2024-12-19 10:30:¶

@pcahyna
I will not do backward incompatible changes now for ReaR 2.8.
I will release ReaR 2.8 backward compatible with ReaR 2.7.

We can re-organize our whole GitHub rear/rear repository
for ReaR 3.0. This would be perfectly fine with me.
But I will not do or implement such a change.
Neither now for ReaR 2.8 nor later for ReaR 3.0.
My reason:
I am not at all a sufficient git expert to do it.

Above I asked for a method to restore a GitHub repository
to a safed "good" state if the repository got messeg up
https://github.com/rear/rear/issues/3238#issuecomment-2536458695
but I got ZERO help.

So do not expect that I will do anything regarding git.

Alternatively please step in now
and do you the ReaR 2.8 release as you prefer it.
I would much appreciate it if I had not to do the release.

schlomo commented at 2024-12-19 10:56:¶

@pcahyna given the broad range of git skills amongst our users I'd prefer to keep things simple and optimize more for the inexperienced git user than the expert.

Personally I'm actually grateful for your insights and consistent push for more git proficiency. I just think that we can't expect that level of motivation to dive deeply into git from all our users.

schlomo commented at 2024-12-19 10:58:¶

@jsmeix I really truly appreciate your effort and willingness to create the release very much, so for me I'd always choose for you to continue what you do and make a compromise somewhere else.

Open Source depends on individual's initiative and nothing is more precious to me than that.

pcahyna commented at 2024-12-19 11:51:¶

given the broad range of git skills amongst our users I'd prefer to keep things simple and optimize more for the inexperienced git user than the expert.

@schlomo that's exactly the point! We should not expect our user to know whether Git prefers a tag or a branch when both of the same name exist. I don't know the rules in this situation either. Therefore, it is better to avoid the situation in the first place.

jsmeix commented at 2024-12-19 12:15:¶

I did "the actual release" right now
and I also created an additional "rear-2.8" branch
as described in
https://github.com/rear/rear/wiki/Release-process

When creating that additional "rear-2.8" branch
GitHub showed this popup text:

A tag already exists with the provided branch name.
Many Git commands accept both tag and branch names,
so creating this branch may cause unexpected behavior.
Are you sure you want to create this branch?

I confirmed to create the branch nevertheless
but I have no idea what unexpected behavior
this branch may cause.
I guess a branch with same name as a tag may
cause unexpected behavior when the branch
contains different sources as what is tagged
so git checkout <branch_name> would result
something different than git checkout <tag_name>.
But in this case here both the 'rear-2.8' branch
and the 'rear-2.8' tag should (hopefully?)
result the same.

jsmeix commented at 2024-12-19 12:23:¶

For the log
what I did for the actual release:

$ git clone https://github.com/rear/rear.git

$ mv rear rear-release

$ cd rear-release

$ git config --global user.email "jsmeix@suse.com"

$ git config --global user.name "Johannes Meixner"

$ git commit -S0C8EBF3CCDDC9692 --allow-empty -m 'ReaR 2.8 release'
[master d9f5befd] ReaR 2.8 release

$ git tag -u 0C8EBF3CCDDC9692 -a rear-2.8 -m "Rear release 2.8"

$ git tag -u 0C8EBF3CCDDC9692 -a 2.8 -m "Rear release 2.8"

$ git push --tags
Username for 'https://github.com': jsmeix
Password for 'https://jsmeix@github.com': 
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 1.95 KiB | 1.96 MiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/rear/rear.git
 * [new tag]           2.8 -> 2.8
 * [new tag]           rear-2.8 -> rear-2.8

$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

$ git push
Username for 'https://github.com': jsmeix
Password for 'https://jsmeix@github.com': 
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/rear/rear.git
   76e80982..d9f5befd  master -> master

Because 'git push --tags' did not push the empty commit
with commit message 'ReaR 2.8 release'
I had to do a subsequent plain 'git push'
to also get that commit pushed.

pcahyna commented at 2024-12-19 12:35:¶

I did "the actual release" right now

🎉

jsmeix commented at 2024-12-19 12:35:¶

I updated
https://github.com/rear/rear/wiki/Release-process
accordingly plus comments so that we can clean up and
improve things for ReaR 3.0 - ideally before the release
and not "by the way" during the actual release process.

jsmeix commented at 2024-12-19 12:42:¶

@rear/contributors
please check if what I did as "ReaR 2.8" release is
actually OK.

What I did as a first check:

$ git clone https://github.com/rear/rear.git
$ mv rear rear-2.8-release
$ cd rear-2.8-release

and at first glance things look OK

$ git tag -l | grep '2\.8'
2.8
rear-2.8

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/add-veeam-support
  remotes/origin/gdha-blockclone
  remotes/origin/jsmeix-SourceTrustworthy
  remotes/origin/jsmeix-get_var_from_file
  remotes/origin/jsmeix-use-TextPrefix
  remotes/origin/master
  remotes/origin/rear-2.4
  remotes/origin/rear-2.5
  remotes/origin/rear-2.6
  remotes/origin/rear-2.7
  remotes/origin/rear-2.8
  remotes/origin/run-in-docker-on-mac
  remotes/origin/secure-boot-auto-configure-v2

$ git log | head -n20
commit d9f5befdda4e0e685e4be09cef6069bc24c39968
Author: Johannes Meixner <jsmeix@suse.com>
Date:   Thu Dec 19 12:51:51 2024 +0100

    ReaR 2.8 release

commit 76e8098254c61b244cb32001adc9e1b71bc8d9a8
Author: Johannes Meixner <jsmeix@suse.com>
Date:   Thu Dec 19 12:47:25 2024 +0100

    WIP: ReaR 2.8 release preparations (#3370)

    rear.8.adoc : Update version number and release date
    sbin/rear : set VERSION and RELEASE_DATE
    rear.spec : set Version
    Update packaging/debian/changelog
    Update packaging/debian/rear.dsc
    Added new doc/rear-release-notes.txt
    see https://github.com/rear/rear/wiki/Release-process#preparation

jsmeix commented at 2024-12-19 13:00:¶

Tomorrow I will do the "Create OBS build" related work
but not via "make obs OFFICIAL=1", see my comment in
https://github.com/rear/rear/wiki/Release-process
why.

I will do the OBS things manually tomorrow.

jsmeix commented at 2024-12-20 07:47:¶

OBS has now
https://build.opensuse.org/package/show/Archiving:Backup:Rear/rear-2.8

Currently build fails there same as for Archiving:Backup:Rear rear-2.7

# osc results -v Archiving:Backup:Rear rear-2.7 | grep failed
xUbuntu_24.04        x86_64     rear-2.7    failed
xUbuntu_22.04        x86_64     rear-2.7    failed
ScientificLinux_7    x86_64     rear-2.7    failed
ScientificLinux_6    i586       rear-2.7    failed
ScientificLinux_6    x86_64     rear-2.7    failed
RHEL_7               x86_64     rear-2.7    failed
RHEL_7               ppc64      rear-2.7    failed
RHEL_6               i586       rear-2.7    failed
RHEL_6               x86_64     rear-2.7    failed
Fedora_39            x86_64     rear-2.7    failed
Debian_12            i586       rear-2.7    failed
Debian_12            x86_64     rear-2.7    failed

but on Archiving:Backup:Rear rear-2.8 I disabled build
for no longer supported distributions according to
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
when build fails there

# osc results -v Archiving:Backup:Rear rear-2.8 | egrep 'failed|disabled'
xUbuntu_24.04        x86_64     rear-2.8    failed
xUbuntu_22.04        x86_64     rear-2.8    failed
ScientificLinux_7    x86_64     rear-2.8    failed
ScientificLinux_6    i586       rear-2.8    disabled
ScientificLinux_6    x86_64     rear-2.8    disabled
RHEL_7               x86_64     rear-2.8    failed
RHEL_7               ppc64      rear-2.8    failed
RHEL_6               i586       rear-2.8    disabled
RHEL_6               x86_64     rear-2.8    disabled
Fedora_39            x86_64     rear-2.8    disabled
Debian_12            i586       rear-2.8    failed
Debian_12            x86_64     rear-2.8    failed

By the way:
I think there is a typo in
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt

ReaR 2.8 is supported on the following Linux operating systems:
     * Fedora 40, 41 (Silverblue not supported)
...
ReaR 2.8 dropped official support for the following Linux operating systems:
     * Fedora < 39

I think the latter must be

     * Fedora < 40

jsmeix commented at 2024-12-20 08:00:¶

OBS Archiving:Backup:Rear rear-2.8 build failure messages:

# osc rbl Archiving:Backup:Rear rear-2.8 xUbuntu_24.04 x86_64
...
dh: error: Compatibility levels before 7 are no longer supported (level 5 requested)
make: *** [debian/rules:4: clean] Error 25

same for xUbuntu_22.04 and Debian_12

On RHEL_7 and ScientificLinux_7
it fails to setup the build system with things like

# osc rbl Archiving:Backup:Rear rear-2.8 RHEL_7 x86_64
...
initializing rpm db...
querying package ids...
Can't locate Digest/MD5.pm in @INC (@INC contains: /.build /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /.build/Build.pm line 24.
BEGIN failed--compilation aborted at /.build/Build.pm line 24.
Compilation failed in require at /.build/getbuildids line 27.
BEGIN failed--compilation aborted at /.build/getbuildids line 27.

and many more of those messages until

Failed to write utmp record: Read-only file system
Powering off.
reboot: Power down

To view the build log file, go to
https://build.opensuse.org/package/show/Archiving:Backup:Rear/rear-2.8
and there in the "Build Results" tab click on a red 'failed' text
which is a link to the matching build log file

jsmeix commented at 2024-12-20 08:03:¶

I cannot fix those build failures
because I don't know about Debian packaging
and I have no idea what the reason could be
why on RHEL_7 and ScientificLinux_7
it fails to setup the build system.

So from my point of view this issue is now done
as far as I could so I close it hereby.

schlomo commented at 2024-12-20 08:06:¶

Big thanks @jsmeix for doing the release, and happy holidays to you and your family!

jsmeix commented at 2024-12-20 08:10:¶

Thank you too for all your various efforts with this release,
in particular for organizing things that helped much
to make this release finally happen!

Also from me happy holidays to you and your family!

gdha commented at 2024-12-20 08:28:¶

@jsmeix I fixed the Ubuntu/Debian builds on OBS. Have a nice holiday break and thank you for your patience during this release. It was much appreciated from us and the User Community will be grateful with this new release after 2 years.

jsmeix commented at 2024-12-20 08:43:¶

@gdha
also to you a nice holiday break!

Thank you for your prompt fix at OBS.
Now even I can see it - in retrospect:
The reason why Ubuntu/Debian builds failed on OBS
was that on OBS there was an old/outdated debian.compat
while here at GitHub it was fixed two years ago via
https://github.com/rear/rear/pull/2882

jsmeix commented at 2024-12-20 08:59:¶

I tried to fix the Ubuntu/Debian builds on OBS also for
rear-2.7 in the same way (i.e. plain '10' in debian.compat)
which makes it build on Debian_12
but other Ubuntu/Debian still fail.

jsmeix commented at 2024-12-20 11:40:¶

@gdha
thank you for also fixing Ubuntu/Debian builds on OBS
for rear-2.7!

# osc log Archiving:Backup:Rear rear-2.7 | head
------------------------------------------------------------------------
r6 | gdha | 2024-12-20 09:07:35 | 925fdeabbccdc3431a11c872bd663108 | 2.7

Update the copyright file

by replacing the old/outdated debian.copyright on OBS
with the current one at GitHub
https://github.com/rear/rear/blob/master/packaging/debian/copyright

Interestingly the current one at GitHub was not changed
since 7 years

# git log -p --follow packaging/debian/copyright
commit 74787aa0b2e637bf129ee0f542733aa27accb084
...
Date:   Sun Sep 24 06:15:51 2017 -0700

so it looks rather strange why the previous one at OBS
was looking so strangely corrupted:

# osc cat -r 5 Archiving:Backup:Rear rear-2.7 debian.copyright
Files: *
Copyright: 2006 Schlomo Schapiro, Gratien D'Haese and other contributors from https://github.com/rear/rear
License: GPL-3 /usr/share/common-licenses/GPL-3
Files: *
Copyright: 2006 Schlomo Schapiro, Gratien D'Haese and other contributors from https://github.com/rear/rear
License: GPL-3 /usr/share/common-licenses/GPL-3
...
[very many more of those entries - in total 1068 such entries]
...
Files: *
Copyright: 2006 Many authors from https://github.com/rear/rear/graphs/contributors
License: GPL-3 /usr/share/common-licenses/GPL-3
Files: *
Copyright: 2006 Many authors from https://github.com/rear/rear/graphs/contributors
License: GPL-3 /usr/share/common-licenses/GPL-3

It looks as if something appended tons of those entries to it?

jsmeix commented at 2024-12-20 11:55:¶

I fixed in Archiving:Backup:Rear rear-2.6
the messed up debian.compat and debian.copyright
with the files from Archiving:Backup:Rear rear-2.7
so that now also rear-2.6 builds for Debian and Ubuntu
BUT
because rear-2.6 is re-built for all distributions
the new build failes now there for

# osc results -v Archiving:Backup:Rear rear-2.6 | grep failed
ScientificLinux_7    x86_64    rear-2.6    failed
RHEL_7               x86_64    rear-2.6    failed
RHEL_7               ppc64     rear-2.6    failed
RHEL_6               x86_64    rear-2.6    failed

same as now for rear-2.7

# osc results -v Archiving:Backup:Rear rear-2.7 | grep failed
ScientificLinux_7    x86_64    rear-2.7    failed
RHEL_7               x86_64    rear-2.7    failed
RHEL_7               ppc64     rear-2.7    failed
RHEL_6               x86_64    rear-2.7    failed

and for rear-2.8

# osc results -v Archiving:Backup:Rear rear-2.8 | grep failed
ScientificLinux_7    x86_64    rear-2.8    failed
RHEL_7               x86_64    rear-2.8    failed
RHEL_7               ppc64     rear-2.8    failed

in rear-2.8 RHEL_6 is disabled - otherwise it would also fail.

jsmeix commented at 2024-12-20 12:00:¶

Regardless that it built for Archiving:Backup:Rear rear-2.8
I also fixed therein the messed up debian.copyright
with the file from Archiving:Backup:Rear rear-2.7

jsmeix commented at 2024-12-20 14:03:¶

For the log:

Right now I tested on
SLES 15 SP 6 with RAID1, LUKS, LVM, and default btrfs structure
the released ReaR 2.8 built as RPM on the openSUSE Build Service
https://build.opensuse.org/package/show/Archiving:Backup:Rear/rear-2.8
for SLE 15 SP3 (the SLE service pack number does not matter for ReaR
because ReaR is only bash scripts, e.g. SP3 versus SP6)
on x86_64 from the openSUSE Build Service RPM download location
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/SLE_15_SP3/x86_64/rear-2.8-3.x86_64.rpm

See
https://github.com/rear/rear/wiki/Test-Matrix-ReaR-2.8#sles-15-sp-6-with-raid1-and-luks-encryption-and-lvm-and-default-btrfs-structure

jsmeix commented at 2024-12-20 14:16:¶

Now (with ReaR 2.8 RPM tested on rather complicated SLES15)
it is really time for me to vacation!

@rear/contributors and all ReaR users who listen here:

I wish you a relaxed and recovering Christmas time
and a Happy New Year!

pcahyna commented at 2024-12-20 18:25:¶

@jsmeix thanks for the whole release process and all the fixes you did along the way!

Merry Christmas and happy new year to you and everyone!

pcahyna commented at 2024-12-20 18:27:¶

For the record: I tested a snapshot soon before the release on RHEL 8, RHEL 9 and RHEL 10, both BIOS and UEFI (x86_64 architecture), LVM layout only.

[Export of Github issue for rear/rear.]

#3238 Issue closed: RFC: Preparations towards release of ReaR 2.8¶

gdha opened issue at 2024-06-05 09:42:¶

jsmeix commented at 2024-06-05 10:42:¶

schlomo commented at 2024-06-05 11:10:¶

jsmeix commented at 2024-06-17 07:23:¶

jsmeix commented at 2024-11-13 07:26:¶

schlomo commented at 2024-11-13 09:05:¶

jsmeix commented at 2024-11-18 16:01:¶

jsmeix commented at 2024-11-19 15:12:¶

jsmeix commented at 2024-11-22 08:43:¶

jsmeix commented at 2024-11-22 08:53:¶

jsmeix commented at 2024-11-25 12:47:¶

jsmeix commented at 2024-11-29 13:44:¶

jsmeix commented at 2024-12-02 15:22:¶

jsmeix commented at 2024-12-03 13:54:¶

gdha commented at 2024-12-04 08:28:¶

jsmeix commented at 2024-12-06 12:45:¶

jsmeix commented at 2024-12-10 11:35:¶

jsmeix commented at 2024-12-10 11:39:¶

jsmeix commented at 2024-12-10 12:27:¶

jsmeix commented at 2024-12-11 15:19:¶

jsmeix commented at 2024-12-11 16:21:¶

jsmeix commented at 2024-12-18 12:09:¶

pcahyna commented at 2024-12-18 12:19:¶

pcahyna commented at 2024-12-18 12:20:¶

jsmeix commented at 2024-12-18 13:08:¶

jsmeix commented at 2024-12-18 13:12:¶

jsmeix commented at 2024-12-18 13:19:¶

schlomo commented at 2024-12-18 13:22:¶

jsmeix commented at 2024-12-18 13:31:¶

schlomo commented at 2024-12-18 13:34:¶

jsmeix commented at 2024-12-18 13:43:¶

jsmeix commented at 2024-12-19 09:24:¶

pcahyna commented at 2024-12-19 10:07:¶

jsmeix commented at 2024-12-19 10:30:¶

schlomo commented at 2024-12-19 10:56:¶

schlomo commented at 2024-12-19 10:58:¶

pcahyna commented at 2024-12-19 11:51:¶

jsmeix commented at 2024-12-19 12:15:¶

jsmeix commented at 2024-12-19 12:23:¶

pcahyna commented at 2024-12-19 12:35:¶

jsmeix commented at 2024-12-19 12:35:¶

jsmeix commented at 2024-12-19 12:42:¶

jsmeix commented at 2024-12-19 13:00:¶

jsmeix commented at 2024-12-20 07:47:¶

jsmeix commented at 2024-12-20 08:00:¶

jsmeix commented at 2024-12-20 08:03:¶

schlomo commented at 2024-12-20 08:06:¶

jsmeix commented at 2024-12-20 08:10:¶

gdha commented at 2024-12-20 08:28:¶

jsmeix commented at 2024-12-20 08:43:¶

jsmeix commented at 2024-12-20 08:59:¶

jsmeix commented at 2024-12-20 11:40:¶

jsmeix commented at 2024-12-20 11:55:¶

jsmeix commented at 2024-12-20 12:00:¶

jsmeix commented at 2024-12-20 14:03:¶

jsmeix commented at 2024-12-20 14:16:¶

pcahyna commented at 2024-12-20 18:25:¶

pcahyna commented at 2024-12-20 18:27:¶

#3238 Issue `closed`: RFC: Preparations towards release of ReaR 2.8¶