Created attachment 1252859 [details]
build.log

Created attachment 1252860 [details]
root.log

Created attachment 1252861 [details]
state.log

It seems that a test-case fails in %check, from the build.log on any architecture of the task from comment #0:

/tmp/bsdcpio_test.2017-02-11T02.20.09-000/test_option_t.log
    ~> a: Sat Feb 11 02:20:13.0988845050 2017
    ~> c: Sat Feb 11 02:20:13.2808855470 2017
    ~> t: Sat Feb 11 02:20:13.2808855470 2017
    ~> 494 B
test_option_t
cpio/test/test_option_t.c:67: Contents don't match
  file="tv.err"
0000_6c_74_2d_62_73_64_63_70_69_6f_3a_20_67_65_74_67_lt-bsdcpio: getg
0010_72_67_69_64_28_31_30_30_30_29_20_66_61_69_6c_65_rgid(1000) faile
0020_64_3a_20_4e_6f_20_73_75_63_68_20_66_69_6c_65_20_d: No such file 
0030_6f_72_20_64_69_72_65_63_74_6f_72_79_0a_31_20_62_or directory.1 b
0040_6c_6f_63_6b_0a_                                 lock.
  expected
0000_31_20_62_6c_6f_63_6b_0a_                        1 block.


The tv.err log has an additional lt-bsdcpio error/warning that is not expected. This should probably get reported and fixed upstream.

The error comes from cpio/cpio.c:lookup_gname_helper

1410         grent = getgrgid((gid_t)id);
1411         if (grent == NULL) {
1412                 *name = NULL;
1413                 if (errno != 0)
1414                         lafe_warnc(errno, "getgrgid(%s) failed",
1415                             cpio_i64toa((int64_t)id));
1416                 return (errno);
1417         }

"No such file or directory" in the tv.err file means ENOENT was returned. 'man getgrgid' suggests that this happens when the GID (here "1000") can not be found or resolved to a groupname.

This problem has been noted in the test-case itself already too. In cpio/test/test_option_t.c the following comment was added after the failing check:

 64         /* List reference archive verbosely, make sure the TOC is correct. */
 65         r = systemf("%s -itv < test_option_t.cpio >tv.out 2>tv.err", testprog);
 66         assertEqualInt(r, 0);
 67         assertTextFileContents("1 block\n", "tv.err");
 68         extract_reference_file("test_option_tv.stdout");
 69 
 70         /* This doesn't work because the usernames on different systems
 71          * are different and cpio now looks up numeric UIDs on
 72          * the local system. */
 73         /* assertEqualFile("tv.out", "test_option_tv.stdout"); */

The "1 block" output is in the "tv.err" file, so it may be sufficient to replace the assertTextFileContents like this?

-       assertTextFileContents("1 block\n", "tv.err");
+       assertFileContainsLinesAnyOrder("tv.err", "1 block\n");


Started a test-build with such a patch added, lets see what happens:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=17933450

(In reply to Niels de Vos from comment #5)
...
> The "1 block" output is in the "tv.err" file, so it may be sufficient to
> replace the assertTextFileContents like this?
> 
> -       assertTextFileContents("1 block\n", "tv.err");
> +       assertFileContainsLinesAnyOrder("tv.err", "1 block\n");
> 
> 
> Started a test-build with such a patch added, lets see what happens:
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=17933450

Failed because the patch does not compile... I'll have to look at how the function is supposed to be called and will update results later (but feel free to continue with it too).

Thanks for working on this.  I tried to submit upstream proposal:
https://github.com/libarchive/libarchive/pull/867

Fedora F26 commits for now:
67fa527e2ada1f497e1a5e2a1a528fb36c29e3fe
b051042a1b5c6feff1e42b80ca7a2d6833b432a3

I'll keep this bug open till we have some upstream response about this
issue.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Backported upstream patch libarchive-3.3.1-cpio-getid.patch in:
http://pkgs.fedoraproject.org/cgit/rpms/libarchive.git/commit/?id=756255ffb6aa76d3c3319a33dafd139d07907298