public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: "Arsen Arsenović" <>
Subject: Re: [PATCH builder.git] master.cfg: add GNU poke builder
Date: Wed, 23 Nov 2022 01:37:13 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.



  parent reply	other threads:[~2022-11-23  0:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-19 23:36 Arsen Arsenović
2022-11-20 11:48 ` Jose E. Marchesi
2022-11-20 12:21   ` Arsen Arsenović
2022-11-20 13:17     ` Frank Ch. Eigler
2022-11-20 14:43       ` Arsen Arsenović
2022-11-20 15:31         ` Frank Ch. Eigler
2022-11-20 16:05           ` Arsen Arsenović
2022-11-20 14:12     ` Jose E. Marchesi
2022-11-23  0:37 ` Mark Wielaard [this message]
2022-11-23 11:53   ` Jose E. Marchesi
2022-11-23 17:44     ` Mark Wielaard
2022-11-23 20:20       ` Mohammad-Reza Nabipoor
2022-11-24 12:11         ` Mark Wielaard
2022-11-28 16:48           ` Frank Ch. Eigler
2022-11-28 19:09             ` Arsen Arsenović
2022-11-28 21:53               ` Frank Ch. Eigler
2022-11-29 11:55                 ` Mohammad-Reza Nabipoor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).