Re: LilyPond | Pipeline #156017999 has failed for dev/hanwen/doc-build | 47b263b1 in !84

[Jonas Hahnfeld]

Am Donnerstag, den 18.06.2020, 09:57 +0200 schrieb Han-Wen Nienhuys:
> On Thu, Jun 18, 2020 at 9:05 AM Jonas Hahnfeld <hahnjo@hahnjo.de> 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.

Ack.

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