Bug#704080: unblock: libarchive/3.0.4-3

[peter green]

It seems that Adam D. Barratt unblocked libarchive to fix the security
bug. Unfortunately that wasn't enough to get the package into testing.

Specifically it seems that s390x has not successfully built this package
for some time (since before s390x stopped being considered a "broken and
fucked" architecture). As a result the s390x package is out of date in
both testing and unstable. Britney will not migrate the package if there
are out of date binaries in unstable (even if there are also out of date
binaries for the same package in testing). The cause of the build
failures seems to be a testsuite failure. Afaict there are several
options in this scenario.

1: someone gets to the bottom of the issue and submits a patch which is
uploaded
2: a version of the package is uploaded where the so that the s390x
version is either built without running the testsuite or where the
testsuite is run but it's failure is considered non-fatal
3: the s390x binaries are removed.
4: the package is forced into testing.

Option 1 is clearly the ideal outcome but relies on someone who has the
time and inclination (and no that won't be me) to get down and debug why
the testsuite isn't passing on s390x and hope that the resulting fix is
small enough for the release team to accept it. Given what this package
does I don't like option 2. Option 3 seems to be blocked by reverse
dependencies (especially cmake). Option 4 doesn't make the current
situation any worse but afaict outdated packages in testing are not
considered acceptable for release.

Thoughts? should I go file a rc bug about this issue?

P.S. I'm just poking through the rc bug list looking at why bugs are
still open in testing. I have no relationship to this package, i'm not
part of the relase team and i'm not a 390x porter.

[Philipp Kern]

Hi,

Post by peter green
Specifically it seems that s390x has not successfully built this
package for some time (since before s390x stopped being considered a
"broken and fucked" architecture). As a result the s390x package is
out of date in both testing and unstable. Britney will not migrate
the package if there are out of date binaries in unstable (even if
there are also out of date binaries for the same package in
testing). The cause of the build failures seems to be a testsuite
failure. Afaict there are several options in this scenario.

my personal guess is that there's probably nothing s390x-specific to it,
it's probably broken with 64bit big endian. The d-ports build for
sparc64 fails as well.

Kind regards
Philipp Kern

[Andreas Henriksson]

Post by Philipp Kern
Hi,

Post by peter green
Specifically it seems that s390x has not successfully built this
package for some time (since before s390x stopped being considered a
"broken and fucked" architecture). As a result the s390x package is
out of date in both testing and unstable. Britney will not migrate
the package if there are out of date binaries in unstable (even if
there are also out of date binaries for the same package in
testing). The cause of the build failures seems to be a testsuite
failure. Afaict there are several options in this scenario.

my personal guess is that there's probably nothing s390x-specific to it,
it's probably broken with 64bit big endian. The d-ports build for
sparc64 fails as well.

Please also note that the current version (available in experimental for now)
seems to build ok on s390x (but fails on other platforms instead)......
Using git bisect should help identify the needed relevant changes.

Help is welcome.

[peter green]

Package: libarchive
Version: 3.0.1b-1
Severity: serious

Note: this bug report is a continuation of discussions in the unblock
bug for libarchive (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704080 ).

Post by Andreas Henriksson

Post by Philipp Kern
my personal guess is that there's probably nothing s390x-specific to it,
it's probably broken with 64bit big endian. The d-ports build for
sparc64 fails as well.

Please also note that the current version (available in experimental for now)
seems to build ok on s390x (but fails on other platforms instead)......
Using git bisect should help identify the needed relevant changes.

I just noticed that the current s390x build was manually built on the
porterbox. There hasn't been a successfull s390x sid buildd build for even
longer. See bug 659294

I just tried to build it on the s390x porterbox and it built
successfully :/

So I diffed the logs (- is the log from the buildd + is my log
from the porterbox). Highlights are below.

65: test_read_disk_directory_traversals
-libarchive/test/test_read_disk_directory_traversals.c:1260: ARCHIVE_EOF != archive_read_next_header2(a, ae)
- Description: There must be no entry
-libarchive/test/test_read_disk_directory_traversals.c:1263: File at has atime 1364403708.000000000, expected 886622.000000000
- Description: Atime should be restored
-libarchive/test/test_read_disk_directory_traversals.c:1524: Assertion failed: strcmp(archive_entry_pathname(ae), "nd/f2") != 0
- Description: File 'nd/f2' should be exclueded
-libarchive/test/test_read_disk_directory_traversals.c:1551: ARCHIVE_EOF != archive_read_next_header2(a, ae)
- Description: There should be no entry
+libarchive/test/test_read_disk_directory_traversals.c:1221: SKIPPING: Can't test atime with nodump on this filesystem
+libarchive/test/test_read_disk_directory_traversals.c:1436: SKIPPING: Can't test nodump on this filesystem
66: test_read_disk_entry_from_file


Totals:
Tests run: 177
- Tests failed: 1
- Assertions checked:12819198
- Assertions failed: 4
- Skips reported: 73
-
-Failing tests:
- 65: test_read_disk_directory_traversals (4 failures)
-
-Details for failing tests: /tmp/libarchive_test.2013-03-27T17.01.30-000
-
-FAIL: libarchive_test
+ Tests failed: 0
+ Assertions checked:12819611
+ Assertions failed: 0
+ Skips reported: 34
+177 tests passed, no failures
+PASS: libarchive_test

13: test_option_b
-tar/test/test_option_b.c:41: File archive1.tar has size 3072, expected 2048
- Description: bsdtar does not pad archives written directly to regular files
-tar/test/test_option_b.c:63: File archive5.tar has size 3072, expected 2048
14: test_option_exclude

20: test_option_nodump
-tar/test/test_option_nodump.c:63: File should not exist: file2
+tar/test/test_option_nodump.c:32: SKIPPING: Can't test nodump on this filesystem
21: test_option_q

Totals:
Tests run: 32
- Tests failed: 2
- Assertions checked: 7490
- Assertions failed: 3
- Skips reported: 1
-
-Failing tests:
- 13: test_option_b (2 failures)
- 20: test_option_nodump (1 failures)
-
-Details for failing tests: /tmp/bsdtar_test.2013-03-27T17.02.00-000
-
-FAIL: bsdtar_test
+ Tests failed: 0
+ Assertions checked: 7468
+ Assertions failed: 0
+ Skips reported: 2
+32 tests passed, no failures
+PASS: bsdtar_test
.
If tests fail or crash, details will be in:
- /tmp/bsdcpio_test.2013-03-27T17.02.06-000
+ /tmp/bsdcpio_test.2013-04-05T16.24.48-000

In summary it seems to me like the testsuite failures are filesystem
dependent.

Now questions for various parties

Libarchive maintainers:
does the testsuite have a method for setting expected failures?

s390x porters and buildd admins:
what fileystem setup do the s390x buildds use for the build environments?

Release team:
should I upload the binary I built on the porterbox so that the security fix can migrate?

[Julien Cristau]

Post by peter green
Thoughts? should I go file a rc bug about this issue?

Yes.

Cheers,
Julien