Re: Race condition with 'make test'?

[Aaron Hill]

On 2021-11-16 2:24 pm, Jean Abou Samra wrote:
> Or what if after a failure you open the file
> build/out/lybook-testdb/snippet-names-[the-sha-printed].log
> directly?

Weird.  The log seems somewhat corrupted:

=====
Processing `08/lily-Processing `08/lily-015b46b4.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
Writing 08/lily-015b46b4-1.signature
Layout output to `08/lily-015b46b4.eps'...
Converting to `08/liConverting to PNG...
Layout output to `0
fatal error: cannot rename `08/lily-015b46b4.eps-page1.png' to 
`08/Writing 08/lily-015b46b4-systems.texi...
Writing 08/lily-015b46b4-systems.tex...
Writing 08/lily-015b46b4-systems.count...
Success: compilation successfully completed
=====


> > I will try earlier tags and then see about bisecting.

Here is the first commit that exhibits the same errors I am getting on 
latest:

commit b0410d890fdcef746a238a07c01f569194b641bb
Author: Thibaut Cuvelier <dourouc05@gmail.com>
Date:   Tue Sep 28 21:11:42 2021 +0000

    DocBook: support tag attributes with a single quote

    Before this patch, DocBook files had to use double quotes for
    attributes:

            <programlisting language="lilypond">

    However, XML makes no distinction with single quotes, like this:

            <programlisting language='lilypond'>

    This patch fixes the regexes to allow for both kinds of delimitation 
of
    attributes. The changes onto the DocBook document still use double
    quotes, irrespective of what the original document used (as they are 
the
    most common).

    Fixes #6185

:040000 040000 d826cbe4e6cfda273ec0ce19a5f4d927fa83358d 
087ec0ad6015893cfd8f94bf0ff2d6212339086b M   input
:040000 040000 12f59687dca61d4514674ae0a22691fa78f70c29 
2923e933d161141583dda3723b2cd0c0d5ec7268 M   python

Backing up one commit still produces an error but at a different point 
in the tests.  The related log also mentions a fatal error about not 
being able to rename something.  This behavior seems to go back to 
release/2.23.0-1.  Builds and tests are taking long enough (and I've got 
other work to do), so I'll have to look at this another day.


-- Aaron Hill