[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LilyPond | Pipeline #156017999 has failed for dev/hanwen/doc-build |

From: Jonas Hahnfeld
Subject: Re: LilyPond | Pipeline #156017999 has failed for dev/hanwen/doc-build | 47b263b1 in !84
Date: Thu, 18 Jun 2020 10:18:19 +0200
User-agent: Evolution 3.36.3

Am Donnerstag, den 18.06.2020, 09:57 +0200 schrieb Han-Wen Nienhuys:
> On Thu, Jun 18, 2020 at 9:05 AM Jonas Hahnfeld <> wrote:
> > > Would you like me to take my runner offline for a bit and trigger a 
> > > rebuild of this pipeline to see whether it will succeed on another runner?
> It's not necessary. I recreated the failing build locally.
> The only difference I could find was that the CI image uses pdftex to
> build out-www/cs/notation.pdf, while the passing build (locally on my
> laptop) uses xetex. The build also passes in a ubuntu 16.04 container
> with xetex installed.
> [...]
> It's "working" with origin/master today because cs/GNUmakefile
> disables PDF generation, I don't know why.

Documentation/ja/GNUmakefile has some pretty good explanations of the
requirements to build PDF files with non-Western fonts. I'd guess the
reasoning is the same for cs.

> > > It would be nice to advance this MR since it seems to take about 25% off 
> > > the time required for the doc stage (on my runner).
> > 
> > Where do you get that 25% from, with no version of the MR passing
> > automated CI testing?
> You can run it locally. There is a significant speedup for parallel builds.

Could you quantify please? Also, are you doing an apples-to-apples
comparison by restricting both builds to the same number of CPUs using
taskset? This should avoid the rewritten build to use more resources
than it's supposed to be.

> Another things to consider (if you build docs locally) if to remove
> extractpdfmark. It is extremely slow.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]