[Pkg-zsh-devel] zsh FTBFS under Salsa CI's reprotest: 'KEY_EVENT' undeclared / blhc CI check disabled / bullseye freeze: zsh is considered a key package

[Daniel Shahaf]

Axel Beckert wrote on Wed, 14 Oct 2020 22:58 +0200:
> Hi Daniel,
> 
> Daniel Shahaf wrote:
> > That test failure can be easily reproduced by adding the 'f' flag to
> > any existing test case that passes, or by writing a new one such as:  
> 
> Ok, I assume this just to see the effect as if it would have failed,
> not the real cause of it, right?

Adding the 'f' flag to a passing test point will exercise the "test was
expected to fail, but passed" failure mode.  It's not about the root
cause of the D02glob failure.  Does this answer your question?

> > So, to summarize:
> > 
> > 1. For the failure in question, the actual stdout and stderr are equal
> > to the expected ones, verbatim.  
> 
> Ok, so eatmydata can't be the cause here, right?

There isn't a libeatmydata.so-related diagnosis on stderr in the test
case (because the stderr can be deduced to be empty), but that doesn't
rule out the possibility that eatmydata might be interfering with the
underlying readdir(3) call in some other way.

> > 4. Upstream issue: How to clarify the "was expected to fail, but
> > passed" message?  
> 
> I think there's nothing to clarify at that point. In the end, it's a
> "fail". Doesn't matter if there's one negation in there or not.

I was thinking of clarifying the error message in upstream's git for
future builders, not in context of this specific thread.

> > (Feel free to continue the relevant parts on -workers at .)  
> 
> At least no more today...

No urgency.  Email threads are allowed to span multiple days ☺

> > > > > P.P.S.: I also wonder if that missing KEY_EVENT thingy could also be
> > > > > triggered by not being able to load some arbitrary .so file.    
> > > > 
> > > > I don't see how, but I suppose it won't hurt to grep «configure &&
> > > > make»'s log/debug output for eatmydata errors.    
> > > 
> > > Yeah, I should probably setup a chroot without eatmydata installed.
> > > I'm admittedly currently too lazy to do that…  
> > 
> > Can't we grep the config.log files that the CI build produces?  
> 
> If the build doesn't succeed, the artefacts just contain that
> reprotest.log file which is also shown as far as I understand.
> 
> The configure output is at
> https://salsa.debian.org/debian/zsh/-/jobs/1066149#L1014, but I assume
> you want that more detailed config.log file. I think that one wouldn't
> be in the artefacts even if the build succeeded.

I was specifically thinking of inspecting the stderr output of failing
configure checks for eatmydata errors, and that information isn't
emitted in configure's output, no.

Cheers,

Daniel