[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Re: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)



This message was last sent to the bug report. Forwarding to debian-hurd in case you didn't get it.

~ Andres
---------- Forwarded message ----------
From: "Tim Kientzle" <tim@kientzle.com>
Date: Feb 13, 2012 1:17 AM
Subject: Re: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
To: <libarchive-discuss@googlegroups.com>
Cc: "Andres Mejia" <amejia004@gmail.com>, <659294@bugs.debian.org>

On Feb 11, 2012, at 1:40 PM, Samuel Thibault wrote:

> Hello,
>
> Andres Mejia, le Fri 10 Feb 2012 16:34:40 -0500, a écrit :
>> Hi. The new version of libarchive uploaded to unstable is failing the
>> test suite (and thus failing to build the deb packages). We're going
>> to need copies of the test directories from the test suites, e.g.,
>>
>>>>  Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000
>>
>> Please provide these test directories to libarchive-discuss@googlegroups.com.
>
> Here they are.

Thank you!  That helps.

So on hurd, I see a couple of interesting failures for bsdtar:

tar/test_copy:  bsdtar is getting a nonsense file mode.

  This test creates a bunch of files and directories with varying
permissions and file name lengths.  One directory (ending in _194)
is getting read as having a file type of 0, which is obviously nonsense.
As a result, it's not getting archived.  The test is recording two failures:
 1) when bsdtar emits an error to stdout when trying to archive
    this directory and
 2) when the directory doesn't appear in the restored copy
This is especially confusing because it's not happening for
any other files or directories in this test.

An strace or truss of the process might clarify things.

tar/test_option_H_upper and tar/test_option_L_upper: restoring incorrect permissions on a symlink to a directory

  The test archives and restores a number of files, directories, and symlinks
to those files and directories.  It looks like symlinks to directories are getting
restored with different permissions than expected (expected 0755,
seeing 0700).

Does hurd handle symlinks to directories differently than other
systems?  Is the configuration script not finding lchmod() or
lstat() correctly?

Again, an strace or truss of the process might clarify things.

You can run a single test by running the bsdtar_test program
manually and specifying the name of the test:

$ bsdtar_test -vvv -p /full/path/to/bsdtar -r /full/path/to/tar/test test_copy

If you can strace or truss this (following children so we find
out what bsdtar is doing as well), that would be appreciated.

Thanks,

Tim Kientzle


Reply to: