These failures are identical on x86 and arm, but do NOT appear on ppc or hppa. test_write_filter_lrzip /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/libarchive/test/test_write_filter_lrzip.c:78: ARCHIVE_OK != archive_write_close(a) ARCHIVE_OK=0 (0x0, 00) archive_write_close(a)=-30 (0xffffffffffffffe2, 01777777777777777777742) errno: 5 detail: Error closing program: lrzip /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/libarchive/test/test_write_filter_lrzip.c:88: ARCHIVE_OK != archive_read_next_header(a, &ae) ARCHIVE_OK=0 (0x0, 00) archive_read_next_header(a, &ae)=1 (0x1, 01) /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/libarchive/test/test_write_filter_lrzip.c:94: ARCHIVE_FILTER_LRZIP != archive_filter_code(a, 0) ARCHIVE_FILTER_LRZIP=10 (0xa, 012) archive_filter_code(a, 0)=0 (0x0, 00) /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/libarchive/test/test_write_filter_lrzip.c:95: "lrzip" != archive_filter_name(a, 0) "lrzip" = "lrzip" (length 5) archive_filter_name(a, 0) = "none" (length 4) /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/libarchive/test/test_write_filter_lrzip.c:123: ARCHIVE_OK != archive_write_close(a) ARCHIVE_OK=0 (0x0, 00) archive_write_close(a)=-30 (0xffffffffffffffe2, 01777777777777777777742) test_option_lrzip /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/tar/test/test_option_lrzip.c:43: 0 != systemf("%s -cf - --lrzip f >archive.out 2>archive.err", testprog) 0=0 (0x0, 00) systemf("%s -cf - --lrzip f >archive.out 2>archive.err", testprog)=256 (0x100, 0400) /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/tar/test/test_option_lrzip.c:51: Assertion failed: s > 2 /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/tar/test/test_option_lrzip.c:52: p != "LRZI\x00" size 5 = 5 Dump of p 0000_00_97_12_5d_00 ...]. Dump of "LRZI\x00" 0000_4c_52_5a_49_00 LRZI. test_option_lrzip /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/cpio/test/test_option_lrzip.c:43: 0 != systemf("echo f | %s -o --lrzip >archive.out 2>archive.err", testprog) 0=0 (0x0, 00) systemf("echo f | %s -o --lrzip >archive.out 2>archive.err", testprog)=256 (0x100, 0400) /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/cpio/test/test_option_lrzip.c:50: Assertion failed: s > 2 /var/tmp/portage/app-arch/libarchive-3.7.2-r2/work/libarchive-3.7.2/cpio/test/test_option_lrzip.c:51: p != "LRZI\x00" size 5 = 5 Dump of p 0000_00_e9_05_00_00 ..... Dump of "LRZI\x00" 0000_4c_52_5a_49_00 LRZI. Reproducible: Always
Created attachment 888488 [details] build.log and emerge --info (x86)
Created attachment 888489 [details] build.log and emerge --info (arm)
The contents of the detailed files are listed out in their entirety in the first post.
It's lrzip being broken: $ touch foo $ lrzip foo Output filename is: foo.lrz Warning, low memory for chosen compression settings Unable to allocate enough memory for operation Failed to open streams in rzip_chunk Fatal error - exiting
Ah, I was extremely confused why this didn't show up on ppc or hppa, it's because I have only 8 cores allocated to the VM for the former, and the latter has only 2 physical cores, but my laptop has 32 threads, and my arm board has 16 cores.
Tried to find a workaround but lrzip.conf doesn't have an option for threads, they don't have an envvar to pass command-line options, and they don't respect CPU affinity.
Ok, I have a good enough workaround.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e114143d342fb2a6fbdce93eac3484af8ad9f1e8 commit e114143d342fb2a6fbdce93eac3484af8ad9f1e8 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-03-25 15:21:06 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-03-25 15:21:34 +0000 app-arch/libarchive: Workaround lrzip bug on 32-bit arch tests Bug: https://bugs.gentoo.org/927766 Signed-off-by: Michał Górny <mgorny@gentoo.org> app-arch/libarchive/libarchive-3.7.2-r2.ebuild | 7 +++++++ 1 file changed, 7 insertions(+)
Can you see if this is also reproducible on app-arch/lrzip-next? It's a fork of the original lrzip that has an active upstream maintainer that I added a few weeks ago.
(In reply to Joshua Kinard from comment #9) > Can you see if this is also reproducible on app-arch/lrzip-next? It's a > fork of the original lrzip that has an active upstream maintainer that I > added a few weeks ago. Seems to be explicitly unsupported. checking size of long... 4 configure: error: Size of long type is 4 bytes. 32 bit processors are NO LONGER supported in lrzip-next
(In reply to matoro from comment #10) > (In reply to Joshua Kinard from comment #9) > > Can you see if this is also reproducible on app-arch/lrzip-next? It's a > > fork of the original lrzip that has an active upstream maintainer that I > > added a few weeks ago. > > Seems to be explicitly unsupported. > > checking size of long... 4 > configure: error: Size of long type is 4 bytes. 32 bit processors are NO > LONGER supported in lrzip-next Derp, I forgot about that. ago's tinderbox script reported that under Bug #925548, so I removed all 32-bit keywords.
