Re: [Lilypond-auto] Patchy email
John,
On 26 August 2012 11:39, John Mandereau wrote:
> Hi James,
>> 09:24:02 (UTC) Begin LilyPond compile, previous commit at
>> d14e4770b85b3cacc647e45b9ebfe59cc085753f
>> 09:24:07 Merged staging, now at:
>> d14e4770b85b3cacc647e45b9ebfe59cc085753f
>> 09:24:08Success:./autogen.sh --noconfigure
>> 09:24:18Success:../configure --disable-optimising
>> 09:24:24Success:nice make clean
>> 09:25:34Success:nice make -j7 CPU_COUNT=7
>> 09:27:51Success:nice make test -j7 CPU_COUNT=7
>> 09:44:13Success:nice make doc -j7 CPU_COUNT=7
>> 09:44:17 *** FAILED STEP ***
>> merge from staging
>> Command '['git', 'log', '-1', 'origin/HEAD..test-staging']' returned
>> non-zero exit status 128
>> fatal: ambiguous argument 'origin/HEAD..test-staging': unknown revision or
>> path not in the working tree.
>> Use '--' to separate paths from revisions
>
> I suppose that your $LILYPOND_GIT git repository has fetch settings
> that differ from ours, so you got this error, and in addition I guess
> that master and HEAD should always be equal on Savannah LilyPond git
> repo. Could please you help me with verifying the first guess by
> answering the following?
>
> 1) What does
>
> cd $LILYPOND_GIT
> git rev-parse origin/HEAD
>
> say?
--snip-
james@jameslilydev2:~/patchy/test-results$ cd $LILYPOND_GIT
james@jameslilydev2:~/lilypond-git$ git rev-parse origin/HEAD
origin/HEAD
fatal: ambiguous argument 'origin/HEAD': unknown revision or path not
in the working tree.
Use '--' to separate paths from revisions
--snip--
>
> 2) What does the [remote "origin"] section of $LILYPOND_GIT/.git/config
> contain?
[remote "origin"]
url = ssh://pkx1...@git.sv.gnu.org/srv/git/lilypond.git
fetch = +refs/heads/*:refs/remotes/origin/*
>
> 3) What does lilypond-patchy-staging say (complete console output) if
> you replace line 334 of patches/compile_lilypond_test/__init__.py
>
> origin_head = remote_branch_name ("HEAD")
>
> with
>
> origin_head = remote_branch_name ("master")
>
> ?
Unfortunately I think that Phil's successful merge will make this
redundant at this moment but I did it anyway
--snip--
>From ssh://git.sv.gnu.org/srv/git/lilypond
+ 9c9d22c...4de3d0d release/unstable -> origin/release/unstable
(forced update)
11:07:22 (UTC) Begin LilyPond compile, previous commit at
d14e4770b85b3cacc647e45b9ebfe59cc085753f
11:07:32Success:No new commits in staging
--snip--
>
> (In case after the change lilypond-patchy-staging says "No new
> commits", clear the value of last_known_good_build in [staging]
> section of ~/.lilypond-patchy-config and rerun
> lilypond-patchy-staging).
ah.. ok :)
--snip--
james@jameslilydev2:~/patchy/patches/compile_lilypond_test$
../lilypond-patchy-staging.py
Everything up-to-date
--snip--
No errors
james
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
Hi James,
> 09:24:02 (UTC) Begin LilyPond compile, previous commit at
> d14e4770b85b3cacc647e45b9ebfe59cc085753f
> 09:24:07 Merged staging, now at:
> d14e4770b85b3cacc647e45b9ebfe59cc085753f
> 09:24:08Success:./autogen.sh --noconfigure
> 09:24:18Success:../configure --disable-optimising
> 09:24:24Success:nice make clean
> 09:25:34Success:nice make -j7 CPU_COUNT=7
> 09:27:51Success:nice make test -j7 CPU_COUNT=7
> 09:44:13Success:nice make doc -j7 CPU_COUNT=7
> 09:44:17 *** FAILED STEP ***
> merge from staging
> Command '['git', 'log', '-1', 'origin/HEAD..test-staging']' returned
> non-zero exit status 128
> fatal: ambiguous argument 'origin/HEAD..test-staging': unknown revision or
> path not in the working tree.
> Use '--' to separate paths from revisions
I suppose that your $LILYPOND_GIT git repository has fetch settings
that differ from ours, so you got this error, and in addition I guess
that master and HEAD should always be equal on Savannah LilyPond git
repo. Could please you help me with verifying the first guess by
answering the following?
1) What does
cd $LILYPOND_GIT
git rev-parse origin/HEAD
say?
2) What does the [remote "origin"] section of $LILYPOND_GIT/.git/config contain?
3) What does lilypond-patchy-staging say (complete console output) if
you replace line 334 of patches/compile_lilypond_test/__init__.py
origin_head = remote_branch_name ("HEAD")
with
origin_head = remote_branch_name ("master")
?
(In case after the change lilypond-patchy-staging says "No new
commits", clear the value of last_known_good_build in [staging]
section of ~/.lilypond-patchy-config and rerun
lilypond-patchy-staging).
Thanks,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
Graham Percival writes: > On Wed, Jul 18, 2012 at 01:58:54PM +0200, David Kastrup wrote: >> John Mandereau writes: >> >> > Sorry for bearing with my move to a more disciplined developer from a >> > hybrid of pyromaniac and fireman of the build system I used to be :-P >> >> It's not really trivial to get into LilyPond development and the >> documentation is not the best. I'd rather have people try and make >> mistakes and improve the documentation for this kind of thing than >> keeping new developers away even before they try. > > Umm, John has approximately 3 times as many commits to his name as > you do. Granted, many of them are from gitstats being counting > "committed by" intead of "author", so translation meisters get > double the number of commits. No, I think "author" is counted, so short of underusing the --author option, this should be accurate. Merges count as well, of course, as long as they are not fastforwards. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
On Wed, Jul 18, 2012 at 01:58:54PM +0200, David Kastrup wrote: > John Mandereau writes: > > > Sorry for bearing with my move to a more disciplined developer from a > > hybrid of pyromaniac and fireman of the build system I used to be :-P > > It's not really trivial to get into LilyPond development and the > documentation is not the best. I'd rather have people try and make > mistakes and improve the documentation for this kind of thing than > keeping new developers away even before they try. Umm, John has approximately 3 times as many commits to his name as you do. Granted, many of them are from gitstats being counting "committed by" intead of "author", so translation meisters get double the number of commits. But still, he did a ton of work on the build system, documentation, set up the whole translations system, etc., and certainly knows more than me about the programming side of lilypond as well. He's just been a bit inactive for the past few years while doing a phd in mathematics in Italy. Which just serves to underline the problem with the CG. When the inaccuracies in the CG mislead extremely experienced lilypond developers, there's clearly a problem. Thankfully John will undoubtedly fix it... but this morning we also saw problems with another person looking at the git part of the CG, so there's still plenty of work to do. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
John Mandereau writes: > Il giorno mer, 18/07/2012 alle 09.27 +0200, David Kastrup ha scritto: >> Well, now the accumulated mess in master is final, anyway. I have >> bumped staging to match it, so nothing is blocked anymore. I am not >> really interested in checking the consistency of all that since it >> consists of manually messing with the results of makelsr, and I have no >> clue about that. It is likely to work at least until the next run of >> makelsr. > > All this mess results from ignorance and "broken implementation" (I > mean here scripts malfunction with respect to documentation) of > policies, management of staging/master on my side and mangagement of > snippets/makelsr on your side, and we both have an "excuse" for this > ignorance: > > - makelsr does not work as advertised in > http://lilypond.org/doc/v2.15/Documentation/contributor/adding-and-editing-snippets > before as well as after last change to makelsr, it unconditionnally > removes every .ly and .snippet-list files in Documentation/snippets, > which is not what you want when you'd like to update one snippet from > Documentation/snippets/new into Documentation/snippets without > downloading and unpacking tarball from LSR web site. No idea. I mean this definitely started with me checking in a documentation snippet that did not work on master and still got through Patchy since I did not expect this to go untested. I even distinctly remember being surprised that this last-minute change worked when rethinking it, and I might not have tested it separately (apart from running Patchy), or with a binary that already accepted it. For the CG, I think we can state "It may happen occasionally that the staging branch breaks automated testing. In this case the automatic move of staging material to master gets halted in order to avoid broken material entering master. This is a safety net. Please don't try breaking out from it by adding fixes on top of staging: in that case the whole sequence will end up in master after all, defeating the purpose of the system. The proper fix usually involves rewriting the staging branch and is best left to core developers after discussion on the developer list." > - I have not found anything in the CG that says that history rewrite is > allowed in staging in order to eliminate/squash/edit commits that break > build, and so that you should make sure to keep your commits safe in > your local tree until they reach master; this is a smart feature allowed > by Patchy/staging/master system, but I realized it after your messages > tonight; this morning I found discussions in the list archives about > this, when I was completely idle in LilyPond development, so my next > patch will be documenting this in the CG. See above for a first draft. > Sorry for bearing with my move to a more disciplined developer from a > hybrid of pyromaniac and fireman of the build system I used to be :-P It's not really trivial to get into LilyPond development and the documentation is not the best. I'd rather have people try and make mistakes and improve the documentation for this kind of thing than keeping new developers away even before they try. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
Il giorno mer, 18/07/2012 alle 09.27 +0200, David Kastrup ha scritto: > Well, now the accumulated mess in master is final, anyway. I have > bumped staging to match it, so nothing is blocked anymore. I am not > really interested in checking the consistency of all that since it > consists of manually messing with the results of makelsr, and I have no > clue about that. It is likely to work at least until the next run of > makelsr. All this mess results from ignorance and "broken implementation" (I mean here scripts malfunction with respect to documentation) of policies, management of staging/master on my side and mangagement of snippets/makelsr on your side, and we both have an "excuse" for this ignorance: - makelsr does not work as advertised in http://lilypond.org/doc/v2.15/Documentation/contributor/adding-and-editing-snippets before as well as after last change to makelsr, it unconditionnally removes every .ly and .snippet-list files in Documentation/snippets, which is not what you want when you'd like to update one snippet from Documentation/snippets/new into Documentation/snippets without downloading and unpacking tarball from LSR web site. - I have not found anything in the CG that says that history rewrite is allowed in staging in order to eliminate/squash/edit commits that break build, and so that you should make sure to keep your commits safe in your local tree until they reach master; this is a smart feature allowed by Patchy/staging/master system, but I realized it after your messages tonight; this morning I found discussions in the list archives about this, when I was completely idle in LilyPond development, so my next patch will be documenting this in the CG. Sorry for bearing with my move to a more disciplined developer from a hybrid of pyromaniac and fireman of the build system I used to be :-P John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
John Mandereau writes: > Il giorno mer, 18/07/2012 alle 00.52 +0200, David Kastrup ha scritto: >> The whole purpose of staging is that changes that should not get into >> master get _caught_ before they move into master (which is permanent). >> If you put "fixes" on _top_ of something bad in staging, the whole mess >> _will_ move into master the next time Patchy catches up. >> >> So _please_ _please_ _please_ _don't_ "fix" staging if you don't know >> _exactly_ what you are doing. If Patchy is deadlocked, it is deadlocked >> in order to stop things moving into master. The proper cure then is to >> _remove_ staging and replace it by a version where the mistake has never >> been made. >> >> _Not_ fudge around until a bunch of bad history is ready to move from >> staging into master. >> > > Sorry for the mess, I was initially very surprised that you rewrote > history in staging (I didn't know it was policy, even if I approve > afterwards the motivations you give), and I didn't get your earlier > emails quickly enough (i.e. before Patchy pushed around 22.40 CET) not > to add more mess. Well, now the accumulated mess in master is final, anyway. I have bumped staging to match it, so nothing is blocked anymore. I am not really interested in checking the consistency of all that since it consists of manually messing with the results of makelsr, and I have no clue about that. It is likely to work at least until the next run of makelsr. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
Il giorno mar, 17/07/2012 alle 22.13 +0200, David Kastrup ha scritto: > It is not quite clear to me how the bug went through my tests, and why > Patchy does not complain (apparently make doc does not compile the "new" > snippets ?!?). Not every change to every source file is checked by Patchy. In this case Documentation/snippets/new is not used in "make doc"; Documentation/snippets/new/README refers to the section of the CG where it tells to run makelsr.py in order to get the snippets in new/ to be built by "make doc", but I'm not sure it has been continuously well supported, I'm looking at this. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
Il giorno mer, 18/07/2012 alle 00.52 +0200, David Kastrup ha scritto: > The whole purpose of staging is that changes that should not get into > master get _caught_ before they move into master (which is permanent). > If you put "fixes" on _top_ of something bad in staging, the whole mess > _will_ move into master the next time Patchy catches up. > > So _please_ _please_ _please_ _don't_ "fix" staging if you don't know > _exactly_ what you are doing. If Patchy is deadlocked, it is deadlocked > in order to stop things moving into master. The proper cure then is to > _remove_ staging and replace it by a version where the mistake has never > been made. > > _Not_ fudge around until a bunch of bad history is ready to move from > staging into master. > Sorry for the mess, I was initially very surprised that you rewrote history in staging (I didn't know it was policy, even if I approve afterwards the motivations you give), and I didn't get your earlier emails quickly enough (i.e. before Patchy pushed around 22.40 CET) not to add more mess. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
David Kastrup writes: > David Kastrup writes: > >> David Kastrup writes: >> >>> Please _don't_ ever push a "fix" on top of a broken staging branch. We >>> want to keep master compiling always. If your fix works, it means that >>> Patchy will move both the broken commit as well as the fix to master. >>> >>> I've cleared both for now and hope that no Patchy has already picked the >>> "fix" up. I'll investigate what to do here. >>> >>> It is not quite clear to me how the bug went through my tests, and why >>> Patchy does not complain (apparently make doc does not compile the "new" >>> snippets ?!?). >>> >>> So we already have one fishy commit in master, but at least it is "make >>> doc" clean. >> >> Pushed a fix to staging on top of master and cleared out your changes >> (after moving them to a private branch so that they don't get lost). >> Let's see what commit Patchy moves to master next, and go from there. > > John, could you _please_ stop "fixing" things in staging? You now > merged master into the diverged staging. This is getting a larger and > larger mess. I am undoing this and hope that at least _this_ will not > get caught by Patchy again. The whole purpose of staging is that changes that should not get into master get _caught_ before they move into master (which is permanent). If you put "fixes" on _top_ of something bad in staging, the whole mess _will_ move into master the next time Patchy catches up. So _please_ _please_ _please_ _don't_ "fix" staging if you don't know _exactly_ what you are doing. If Patchy is deadlocked, it is deadlocked in order to stop things moving into master. The proper cure then is to _remove_ staging and replace it by a version where the mistake has never been made. _Not_ fudge around until a bunch of bad history is ready to move from staging into master. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
David Kastrup writes: > David Kastrup writes: > >> Please _don't_ ever push a "fix" on top of a broken staging branch. We >> want to keep master compiling always. If your fix works, it means that >> Patchy will move both the broken commit as well as the fix to master. >> >> I've cleared both for now and hope that no Patchy has already picked the >> "fix" up. I'll investigate what to do here. >> >> It is not quite clear to me how the bug went through my tests, and why >> Patchy does not complain (apparently make doc does not compile the "new" >> snippets ?!?). >> >> So we already have one fishy commit in master, but at least it is "make >> doc" clean. > > Pushed a fix to staging on top of master and cleared out your changes > (after moving them to a private branch so that they don't get lost). > Let's see what commit Patchy moves to master next, and go from there. John, could you _please_ stop "fixing" things in staging? You now merged master into the diverged staging. This is getting a larger and larger mess. I am undoing this and hope that at least _this_ will not get caught by Patchy again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
David Kastrup writes: > Please _don't_ ever push a "fix" on top of a broken staging branch. We > want to keep master compiling always. If your fix works, it means that > Patchy will move both the broken commit as well as the fix to master. > > I've cleared both for now and hope that no Patchy has already picked the > "fix" up. I'll investigate what to do here. > > It is not quite clear to me how the bug went through my tests, and why > Patchy does not complain (apparently make doc does not compile the "new" > snippets ?!?). > > So we already have one fishy commit in master, but at least it is "make > doc" clean. Pushed a fix to staging on top of master and cleared out your changes (after moving them to a private branch so that they don't get lost). Let's see what commit Patchy moves to master next, and go from there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
John Mandereau writes: > Hi David, > Il giorno mar, 17/07/2012 alle 20.19 +0200, lilypond-a...@mandereau.net > ha scritto: >> 18:02:01 (UTC) Begin LilyPond compile, previous commit at >> 7d195ce54c3fd467a1434d5399930d6610327e69 >> >> 18:02:51 Merged staging, now at: >> f22c889b1389cb7d761580762fe77973780f2f86 >> >> 18:02:52 Success:./autogen.sh --noconfigure >> >> 18:03:01 Success:../configure --disable-optimising >> >> 18:03:15 Success:nice make clean -j3 CPU_COUNT=3 >> >> 18:04:44 Success:nice make -j3 CPU_COUNT=3 >> >> 18:09:10 Success:nice make test -j3 CPU_COUNT=3 >> >> 18:19:48 *** FAILED BUILD *** >> >> nice make doc -j3 CPU_COUNT=3 >> >> Previous good commit: 7d195ce54c3fd467a1434d5399930d6610327e69 >> >> Current broken commit: f22c889b1389cb7d761580762fe77973780f2f86 >> >> 18:19:48 *** FAILED STEP *** >> >> merge from staging >> >> Failed runner: nice make doc -j3 CPU_COUNT=3 >> >> See the log file log-staging-nice-make-doc--j3-CPU_COUNT=3.txt > > LilyPond processing of Documentation/snippets/out/incipit.ly from this > failed Patchy run is attached. > > It seems this failure is not related to translated texidocs, nor my last > changes to makelsr and the build system. A freshly built lilypond > compiled succesfully Documentation/snippets/incipit.ly, so I just pushed > the following change, let's see what next Patchy run will tell. If you > have a better fix, please take over. Please _don't_ ever push a "fix" on top of a broken staging branch. We want to keep master compiling always. If your fix works, it means that Patchy will move both the broken commit as well as the fix to master. I've cleared both for now and hope that no Patchy has already picked the "fix" up. I'll investigate what to do here. It is not quite clear to me how the bug went through my tests, and why Patchy does not complain (apparently make doc does not compile the "new" snippets ?!?). So we already have one fishy commit in master, but at least it is "make doc" clean. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
Hi David,
Il giorno mar, 17/07/2012 alle 20.19 +0200, lilypond-a...@mandereau.net
ha scritto:
> 18:02:01 (UTC) Begin LilyPond compile, previous commit at
> 7d195ce54c3fd467a1434d5399930d6610327e69
>
> 18:02:51 Merged staging, now at: f22c889b1389cb7d761580762fe77973780f2f86
>
> 18:02:52 Success:./autogen.sh --noconfigure
>
> 18:03:01 Success:../configure --disable-optimising
>
> 18:03:15 Success:nice make clean -j3 CPU_COUNT=3
>
> 18:04:44 Success:nice make -j3 CPU_COUNT=3
>
> 18:09:10 Success:nice make test -j3 CPU_COUNT=3
>
> 18:19:48 *** FAILED BUILD ***
>
> nice make doc -j3 CPU_COUNT=3
>
> Previous good commit: 7d195ce54c3fd467a1434d5399930d6610327e69
>
> Current broken commit: f22c889b1389cb7d761580762fe77973780f2f86
>
> 18:19:48 *** FAILED STEP ***
>
> merge from staging
>
> Failed runner: nice make doc -j3 CPU_COUNT=3
>
> See the log file log-staging-nice-make-doc--j3-CPU_COUNT=3.txt
LilyPond processing of Documentation/snippets/out/incipit.ly from this
failed Patchy run is attached.
It seems this failure is not related to translated texidocs, nor my last
changes to makelsr and the build system. A freshly built lilypond
compiled succesfully Documentation/snippets/incipit.ly, so I just pushed
the following change, let's see what next Patchy run will tell. If you
have a better fix, please take over.
commit 3301083603577a891757ef798bae3db694cbcca0
Author: John Mandereau
Date: Tue Jul 17 21:56:42 2012 +0200
Quickly fix documentation build
diff --git a/Documentation/snippets/incipit.ly
b/Documentation/snippets/incipit.ly
index 44b79af..1b28967 100644
--- a/Documentation/snippets/incipit.ly
+++ b/Documentation/snippets/incipit.ly
@@ -37,7 +37,7 @@ incipit =
instrumentName = #instrument-name
\override VerticalAxisGroup
#'Y-extent = #'(-4 . 4)
-} #incipit-music
+} { #incipit-music }
}
\layout { $(ly:grob-layout grob)
line-width = \indent
diff --git a/Documentation/snippets/new/incipit.ly
b/Documentation/snippets/new/incipit.ly
index 56ad841..38ade69 100644
--- a/Documentation/snippets/new/incipit.ly
+++ b/Documentation/snippets/new/incipit.ly
@@ -29,7 +29,7 @@ incipit =
instrumentName = #instrument-name
\override VerticalAxisGroup
#'Y-extent = #'(-4 . 4)
-} #incipit-music
+} { #incipit-music }
}
\layout { $(ly:grob-layout grob)
line-width = \indent
Cheers,
John
Processing `/tmp/lilypond-autobuild/build/out/lybook-db/ac/lily-056c8cf0.ly'
Parsing...
Renaming input to: `incipit.ly'
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
/tmp/lilypond-autobuild/build/out/lybook-db/ac/lily-056c8cf0.ly:57:31: error: syntax error, unexpected SCM_TOKEN
}
#incipit-music
/tmp/lilypond-autobuild/build/out/lybook-db/ac/lily-056c8cf0.ly:53:27: error: errors found, ignoring music expression
{ \context MensuralStaff \with {
/tmp/lilypond-autobuild/build/out/share/lilypond/current/ly/init.ly:86:0: error: error in #{ ... #}
#(let ((book-handler (if (defined? 'default-toplevel-book-handler)
warning: no systems found in \score markup, does it have a \layout block?
/tmp/lilypond-autobuild/build/out/lybook-db/ac/lily-056c8cf0.ly:57:31: error: syntax error, unexpected SCM_TOKEN
}
#incipit-music
/tmp/lilypond-autobuild/build/out/lybook-db/ac/lily-056c8cf0.ly:53:27: error: errors found, ignoring music expression
{ \context MensuralStaff \with {
/tmp/lilypond-autobuild/build/out/share/lilypond/current/ly/init.ly:86:0: error: error in #{ ... #}
#(let ((book-handler (if (defined? 'default-toplevel-book-handler)
warning: no systems found in \score markup, does it have a \layout block?
/tmp/lilypond-autobuild/build/out/lybook-db/ac/lily-056c8cf0.ly:57:31: error: syntax error, unexpected SCM_TOKEN
}
#incipit-music
/tmp/lilypond-autobuild/build/out/lybook-db/ac/lily-056c8cf0.ly:53:27: error: errors found, ignoring music expression
{ \context MensuralStaff \with {
/tmp/lilypond-autobuild/build/out/share/lilypond/current/ly/init.ly:86:0: error: error in #{ ... #}
#(let ((book-handler (if (defined? 'default-toplevel-book-handler)
warning: no systems found in \score markup, d
Re: [Lilypond-auto] Patchy email
Il giorno gio, 24/05/2012 alle 18.28 +0200, lilypond-a...@mandereau.net ha scritto: > 16:28:01 Begin LilyPond compile, commit: > bd3c92cbe6edabb9a006ff76290012aa8f8ed13a > > 16:28:03 *** FAILED STEP *** > > merge from staging > > maybe somebody pushed a commit directly to master? > > Please ignore, I restarted my computer without unlocking the needed ssh key. -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
