autopkgtests failures on i386 and s390x for 5.4.0, assumes wrong architecture
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libreoffice (Ubuntu) |
Fix Released
|
High
|
Olivier Tilloy |
Bug Description
Looking at autopkgtests failures on i386 and s390x for 1:5.4.0-0ubuntu2 in artful-proposed (logs attached).
The following linker failure:
/usr/bin/ld: cannot find -ljawt
is due to $JAVA_PROC_TYPE being incorrect ("amd64" instead of "i386" or "s390x"), and thus $LINK_JAVA_LIBS has the incorrect architecture in its path and the linker doesn't find libjawt.so.
This is likely caused by $PROCTYPE being incorrect, which itself is set from $PLATFORMID.
There are other hints that $PROCTYPE has a wrong value in the logs, even though that doesn't appear to make the tests fail:
[…]
mkdir -p /tmp/tmp.
[…]
which means $UNOPKG_PLATFORM has an incorrect value, set from $PROCTYPE.
Changed in libreoffice (Ubuntu): | |
status: | Triaged → In Progress |
tags: | added: block-proposed |
tags: | removed: block-proposed |
PLATFORMID is set in debian/rules:
debian/ rules:569: PLATFORMID := $(shell grep PLATFORMID debian/ vars.$( DEB_HOST_ ARCH) | cut -d"=" -f2)
and unsurprisingly:
./debian/ vars.i386: 1:PLATFORMID= linux_x86 vars.s390x: 1:PLATFORMID= linux_s390x vars.amd64: 1:PLATFORMID= linux_x86_ 64
./debian/
./debian/
I'm wondering whether DEB_HOST_ARCH could be always (incorrectly) expanded to amd64 in the context of the autopkgtest runner?