lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fail to merge staging - make doc is failing


From: James
Subject: Re: Fail to merge staging - make doc is failing
Date: Sun, 15 Sep 2013 17:28:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8

Hello,

Well I stepped away for a couple of hours (Patchy runs every hour or so) and now it is merged.

?

Anyway I can still see two Head/Staging entries

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=00216e16c717470ae53dbbfd1d52850d1b102e29

and

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=6b79234fbfe9400cac355a7b3d7da90532d82522

James

On 15/09/13 15:05, David Kastrup wrote:
James <address@hidden> writes:

Hello,

I cannot merge staging with master as there is an error during make doc.
Currently the only commit in staging that is not in master is

commit 6b79234fbfe9400cac355a7b3d7da90532d82522 (origin/staging, issue3554)
Author: David Kastrup <address@hidden>
Date:   Sun Sep 15 11:01:06 2013 +0200

     Issue 3554: Avoid empty grammar rules using @$ for getting a source 
location
Several rules use @$ for getting the source position from an empty
     rule, but Bison does not even provide a source position for empty
     rules.
This patch fixes most cases by letting different non-empty rules
     assign the respective source positions.  The case of #{ #} cannot be
     fixed in that manner since there is not a single token providing a
     source position in the whole production.  Fixing this particular case
     would require a different technique.

And that commit does not seem very likely to cause that symptom.  Unless
there is something else involved.  Can you check whether this is the
staging/master combination that you are having problems with?

--snip--

orking into jobs:  (1614 1613 1612 1611 1610 1609 1608 1607)
logfile lilypond-multi-run-3.log (exit 1):
Layout output to
/tmp/build-lilypond-autobuild/out/lybook-db/57/lily-ffb6e70b-1.eps'...
Converting to
/tmp/build-lilypond-autobuild/out/lybook-db/57/lily-ffb6e70b-1.pdf'...
Writing
/tmp/build-lilypond-autobuild/out/lybook-db/57/lily-ffb6e70b-systems.texi...
Writing
/tmp/build-lilypond-autobuild/out/lybook-db/57/lily-ffb6e70b-systems.tex...
Writing
/tmp/build-lilypond-autobuild/out/lybook-db/57/lily-ffb6e70b-systems.count...
Processing `/tmp/build-lilypond-autobuild/out/lybook-db/90/lily-68ca9147.ly'
Parsing...
Renaming input to: `/tmp/lilypond-autobuild/input/regression/in-note.ly'
Interpreting music...[8][16][24][32][40][48]
Preprocessing graphical objects...Backtrace:
In
Exception during displaying of backtrace: wrong-type-arg

/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/stencil.scm:56:7:
In procedure fold in expression (fold (lambda #
  #) (car stils) ...):
/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/stencil.scm:56:7:
Wrong type argument in position ~A (expecting ~
A): ~S
That's stack-stencils-padding-list, used for the word-wrapping kinds of
markup commands.

Assuming the 'in-note.ly' is at fault here (this is what
90/lily-68ca9147.ly' is), this is
That does not make a whole lot of sense:

\sourcefilename "/tmp/lilypond-autobuild/input/regression/in-note.ly"
\sourcefileline 0
\version "2.17.6"

\header {
   texidoc = "LilyPond does in-notes.
"
}
And that's everything that _is_ in the snippet regarding the doc run!
The rest should have already complained during "make test":

I seem to remember that we had the same problem (namely in
stack-stencils-padding-list) somewhat recently but don't remember what
it was exactly related to.





reply via email to

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