Bug#1051239: bookworm-pu: package dar/2.7.8-2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: dar@packages.debian.org
Control: affects -1 + src:dar
[ Reason ]
A bug was recently reported to Debian as #1050663, and subsequently to upstream.
This bug causes dar to create isolated catalog files that cannot be read by a
future dar invocation. The catalog files are used as the basis for backups, so
this breaks users' backup flows.
Upstream has not yet pinned down the cause for the issue; however, reports are
that it looks tied to gcc versions 12 or above. This version does exist in
bookworm.
A workaround patch has been developed that mitigates the problems on all tested
systems. I have already applied that patch to 2.7.12-1, which is uploaded to
unstable. The same patch applies to 2.7.8.
We are not yet certain of the trigger of the issue. It is possible that some
binary builds on some archs in bookworm are not impacted. However, for maximum
safety, this patch should be included.
[ Impact ]
While the initial full backup will be created fine, attempts to create future
incremental or differential backups could fail with a dar crash due to this
issue.
Reducing the impact of the issue: the issue only arises when --on-fly-isolate is
used. That is not the only way to create an isolated catalog, and isolated
catalogs are not used in every workflow. Also, the backups that dar does create
are fully intact. However, a script that doesn't check the exit status of dar
may believe a backup was successfully created when it was not.
[ Tests ]
There is no automated test suite over this part of the code. However, the patch
has been tested on the dar mailing list, including on Debian.
[ Risks ]
The patch is trivial. Detection of corrupted catalogs should be fairly
immediate as well.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
This includes just the small patch to address the issue.
[ Other info ]
Please advise whether or not the upload to bookworm should be source-only.
diff -Nru dar-2.7.8/debian/changelog dar-2.7.8/debian/changelog
--- dar-2.7.8/debian/changelog 2022-12-04 08:57:33.000000000 -0600
+++ dar-2.7.8/debian/changelog 2023-09-04 15:07:26.000000000 -0500
@@ -1,3 +1,10 @@
+dar (2.7.8-2) bookworm; urgency=high
+
+ * Include a patch that can prevent issues with creating isolated catalogs
+ with dar built using gcc 12 or newer. Closes: #1050663.
+
+ -- John Goerzen <jgoerzen@complete.org> Mon, 04 Sep 2023 15:07:26 -0500
+
dar (2.7.8-1) unstable; urgency=medium
* New upstream release.
diff -Nru dar-2.7.8/debian/patches/series dar-2.7.8/debian/patches/series
--- dar-2.7.8/debian/patches/series 2022-12-04 08:57:33.000000000 -0600
+++ dar-2.7.8/debian/patches/series 2023-09-04 15:07:12.000000000 -0500
@@ -2,3 +2,4 @@
fix_dcf_path.patch
fix_Hurd_FTBFS.patch
link_with_assuan.patch
+slice_layout.cpp-remove_ternary_operator.patch
diff -Nru dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch
--- dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch 1969-12-31 18:00:00.000000000 -0600
+++ dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch 2023-09-04 15:07:02.000000000 -0500
@@ -0,0 +1,21 @@
+Description: Fix on-fly-isolate with recent GCC #1050663
+Author: Thomas <dar.support.ml-202308@racbu.de>
+Last-Update: 2023-08-30
+
+---
+
+--- DAR_a/src/libdar/slice_layout.cpp 2023-09-02 09:08:49.657051708 +0200
++++ DAR_b/src/libdar/slice_layout.cpp 2023-09-02 09:11:39.240669572 +0200
+@@ -54,7 +54,11 @@ namespace libdar
+
+ void slice_layout::write(generic_file & f) const
+ {
+- char tmp = older_sar_than_v8 ? OLDER_THAN_V8 : V8;
++ char tmp = V8;
++ if(older_sar_than_v8)
++ {
++ tmp = OLDER_THAN_V8;
++ }
+ first_size.dump(f);
+ other_size.dump(f);
+ first_slice_header.dump(f);
Reply to: