On Mon, Oct 16, 2023 at 06:26:50PM -0300, Santiago Ruano Rincón wrote:
Oi Athos,
Hey Santiago!
isc-dhcp is FTBFS on s390x, and I think it is keama-related.
It is, I am sorry for not spotting this earlier.
The relevant part of a (giveback) build log:
[snip]
cat /tmp/keama-test-errors
configdata4.in4 doesn't provide expected output
test -f /tmp/keama-test-errors
test ! -s /tmp/keama-test-errors
make[1]: *** [debian/rules:83: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:42: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
[snip]
Full log:
https://buildd.debian.org/status/fetch.php?pkg=isc-dhcp&arch=s390x&ver=4.4.3-P1-3&stamp=1694824585&raw=0
Do you have any idea why?
Yes. After some debugging, I realized that the upstream tests assume
that the tests will run in a little-endian machine.
keama/tests/configdata4.in4 has
min-secs 20;
and
keama/tests/configdata4.out has
// {
// "name": "min-secs",
// "code": 14,
// "value": 5120
// },
It uses libc's ntohs function to convert that value from network byte
order to the host's byte order.
In little endian machines, it will convert 20 into 5120. However, if we
are in big endian manchines (e.g., s390x), it will convert 20 into 20
(noop).
Here is a small reproducer:
#include <arpa/inet.h>
#include <stdio.h>
void main() {
uint8_t a = 1;
printf("%d\n", ntohs(a));
}
This should print 20 in x86_64 and print 1 in s390x.
While this could drive additional discutions [1] such as whether a
configuration file used in one architecture should only be converted in
a computer using the same architecture and should be intended to be used
in the same architecture, this specific configuration directive
(min-secs) is not yet supported by kea (note that the converted
configuration snippet is commented out, and if you check
keama/tests/configdata4.out, there are additional comments pointing the
lack of support out and a link to an upstream bug).
Therefore, I am inclined to patch the test suite so that the min-secs
value in that test (and in the test expectation) is set to 0 (zero),
which would cover both little and big endian systems, but will no longer
test the conversion. Then, I will also file an upstream bug to discuss
[1] and check whether the tests should support s390x systems.
Thoughts?
--
Athos Ribeiro
