Re: [PATCH builder.git] master.cfg: add GNU poke builder

[Mark Wielaard <mark@klomp.org>]

Hi Arsen,

On Sun, Nov 20, 2022 at 12:36:45AM +0100, Arsen Arsenović via Buildbot wrote:
> - What distros and CPUs do we want to test on?
> 
>   I think at least s390x in conjunction with x86_64 would be useful, to provide
>   a reference for big endian machines, to detect if we're accidentally relying
>   on endianness.
> 
>   It would probably be useful to test on Debian stable+testing and Fedora
>   latest+rawhide, just to make sure we work in both in the past and in the
>   future; though, it's probably less significant than CPU choices.
> 
>   I only left debian-testing in in the current revision of the patch, which has
>   UNSUPPORTED tests due to libtextstyle.

So for now lets only use debian-testing to see how things go.

BTW. I tried on debian-i386, but got some test failures/crashes:

The following patch seems to fix that:

diff --git a/libpoke/pkl-lex.l b/libpoke/pkl-lex.l
index 4c9b013e..ef562ccb 100644
--- a/libpoke/pkl-lex.l
+++ b/libpoke/pkl-lex.l
@@ -176,7 +176,7 @@ build_overflow_error_msg (uint64_t value, int width)
                         : "");
 
   asprintf (&msg,
-            "signed overflow\ntry: %luU%s as int<%d>",
+            "signed overflow\ntry: %" PRIu64 "U%s as int<%d>",
             value, suffix, width);
   return msg;
 }

> - Which check do we run?
> 
>   I initially tried running distcheck, but automake would delete the resulting
>   test run AFAICT.  I'm not entirely sure how to work around that yet (and the
>   night is catching up with me at this point).  As a result, I switched to just
>   check.  Would distcheck even benefit us on CI?  My current thinking is "maybe
>   not", and it does result in compiling poke twice, FWIW.

I changed the distcheck step to a normal make check step.

> ... and, of course, the rest of the patch is up for discussion ;)

It looks good. Pushed.

The only thing that concerns me a little is the ./bootstrap step.
That seems to pull in all of gnulib on every build. We might want to
see if that can be cached somehow. In general ./bootstrap seems to
take longer than a make && make check.

Cheers,

Mark