@@This is an auto-filed bug@@ If you think that a different summary clarifies the issue better, feel free to change it Issue: sys-apps/kbd fails tests. Discovered on: sparc NOTE: If you need further logs, feel free to ask.
Created attachment 644280 [details] build.log build log and emerge --info
Please attach tests/testsuite.log.
I'm unable to reproduce this, so I'm unblocking the stable request.
(In reply to Mike Gilbert from comment #3) > I'm unable to reproduce this, so I'm unblocking the stable request. Usually I don't like arguing for fun, so this is just my opinion: While you (saying you but is a general concept) are asking for a stable request, you are asking the arch team to verify the package on a particular architecture. If the people you have asked to verify finds a bug, I guess it should be considered valid and confirmed. If from further tests we verify that it s an AT fault then we can unblock the stabilization; otherwise, in my opinion, it make no sense. It looks like you don't trust the report. I understand your point of view since you can't reproduce, but if this is not an urgent security hole we can wait a bit to understand the problem.
(In reply to Agostino Sarubbo from comment #4) I unblocked it so that other people would actually test the package.
(In reply to Agostino Sarubbo from comment #4) > If from further tests we verify that it s an AT fault then we can unblock > the stabilization; otherwise, in my opinion, it make no sense. It looks like > you don't trust the report. These automated reports without sufficient information are not terribly useful. If you provided more information up front, I might not have made the same decision.
To expand a bit further on my thought process: With the information I have available, I know that the tests pass on ~amd64, and fail on sparc. That tells me there is probably some arch-specific issue, or some issue between ~arch and arch. If I had test-suite.log available, there might be further evidence indicating an arch-independent bug. But I don't have that file, and I must work with the limited information you have given me. I assume that once a stable request bug has been blocked by a test failure bug, arch teams will ignore the stable request. Is that assumption valid? Assuming it is valid, I don't want to block other arch teams from testing this package. It is possible/likely that it works just fine on most archs.
Created attachment 644372 [details] test logs The relevant one is this: FAIL: dumpkeys-bkeymap ====================== ++ readlink -ev . + cwd=/var/tmp/portage/sys-apps/kbd-2.2.0-r2/work/kbd-2.2.0/tests + cd /var/tmp/portage/sys-apps/kbd-2.2.0-r2/work/kbd-2.2.0/tests + rc=0 ++ mktemp ./temp.XXXXXXXXX + temp=./temp.HK4tsKB7q + datadir=. + ./libkeymap-bkeymap ./../data/keymaps/i386/qwerty/defkeymap.map + cmp -s ./data/dumpkeys-bkeymap/bkeymap.bin ./temp.HK4tsKB7q + rc=1 + '[' 1 '!=' 0 ']' + printf 'failed\n' failed + exit 1 FAIL dumpkeys-bkeymap (exit status: 1)
This apparently fails on bot 32-bit and 64-bit sparc.
Created attachment 644388 [details] temporary file of failing test The testfile from hppa, where it fails the same.
Thanks. I'm guessing this might be a big/little-endian issue, and I'll take a look at the file to confirm that.
ago confirmed that this passes on ARM (little-endian) and fails on PowerPC (big-endian).
Created attachment 644494 [details] test-suite.log test-suite.log on ppc
Created attachment 644496 [details] test-suite.log test-suite.log on ppc64
Created attachment 644498 [details] test-suite.log test-suite.log on s390
In src/libkeymap/dump.c we have: int lk_dump_bkeymap(struct lk_ctx *ctx, FILE *fd) { ... int v = lk_get_key(ctx, i, j); if (fwrite(&v, sizeof(v), 1, fd) != 1) goto fail; ... } The fwrite works for litte-endian, but for big-endian bytes are swapped.
This is a faulty test case, and should not block stabilization.
