Bug#993750: rgtk2: FTBFS on s390x: smoke-test failure: caught segfault

Simon McVittie

2021-09-06 08:50:01 UTC

Please explain what a smoke-test failure is.

Sorry, I thought this was a common term.

A smoke-test for hardware: plug in the device and see whether smoke
comes out. If yes, reject it. If not, it *might* work as intended (but
further testing would be needed to know that).

By analogy, a smoke-test for software: try to do something superficial
with it, like loading it but not running any real tests. If that fails,
reject it (as the R build system does here). If not, it might work
(but further testing would be needed to know that).

A segfault here usually means /some/ API along
the way changed :-/ and is rare as a one-arch-only occurrence.

This happened on s390x buildds consistently across two builds of the
+b2 binNMU, but I can't reproduce it on the s390x porterbox zelenka
in either a sid or bullseye chroot, which is odd. I've given back the
official buildd build to see whether it was something transient.

s390 porters: are there any important differences between the s390x
porterbox and the s390x buildds, like a different CPU or something?

On the porterbox, I get the same output as on the non-s390x buildds:
rgtk can't actually initialize because there's no X11 display, but
doesn't crash either.

make[1]: Leaving directory '/home/smcv/rgtk2-2.20.36/src'
installing to /home/smcv/rgtk2-2.20.36/debian/r-cran-rgtk2/usr/lib/R/site-library/00LOCK-rgtk2-2.20.36/00new/RGtk2/libs
** R
** demo
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
R session is headless; GTK+ not initialized.
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
R session is headless; GTK+ not initialized.
** testing if installed package keeps a record of temporary installation path
* DONE (RGtk2)

smcv