| Summary: | sys-apps/kbd fails test dumpkeys-bkeymap on big-endian archs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | Keywords: | TESTFAILURE |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/legionus/kbd/issues/40 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
test logs temporary file of failing test test-suite.log test-suite.log test-suite.log |
||
|
Description
Agostino Sarubbo
2020-06-10 12:00:09 UTC
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. |
