Patchy email

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Patchy email

patchy
14:39:40 (UTC) Begin LilyPond compile, previous commit at 1c51a616e289fffb918942c8f1e189ab50809157
14:39:51 Merged staging, now at: 1c51a616e289fffb918942c8f1e189ab50809157
14:39:52 Success: ./autogen.sh --noconfigure
14:40:08 Success: /tmp/lilypond-autobuild/configure --enable-checking
14:40:11 Success: nice make clean
14:44:20 Success: nice make -j9 CPU_COUNT=9
14:47:28 *** FAILED BUILD ***
        nice make test -j9 CPU_COUNT=9
        Previous good commit: 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
        Current broken commit: 1c51a616e289fffb918942c8f1e189ab50809157
14:47:28 *** FAILED STEP ***
        merge from staging
        Failed runner: nice make test -j9 CPU_COUNT=9
See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
14:47:28 Traceback (most recent call last):
  File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
    self.build (issue_id=issue_id)
  File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
    issue_id)
  File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
    raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
[hidden email] writes:

> 14:39:40 (UTC) Begin LilyPond compile, previous commit at 1c51a616e289fffb918942c8f1e189ab50809157
> 14:39:51 Merged staging, now at: 1c51a616e289fffb918942c8f1e189ab50809157
> 14:39:52 Success: ./autogen.sh --noconfigure
> 14:40:08 Success: /tmp/lilypond-autobuild/configure --enable-checking
> 14:40:11 Success: nice make clean
> 14:44:20 Success: nice make -j9 CPU_COUNT=9
> 14:47:28 *** FAILED BUILD ***
> nice make test -j9 CPU_COUNT=9
> Previous good commit: 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
> Current broken commit: 1c51a616e289fffb918942c8f1e189ab50809157
> 14:47:28 *** FAILED STEP ***
> merge from staging
> Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
> 14:47:28 Traceback (most recent call last):
>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
>     self.build (issue_id=issue_id)
>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
>     issue_id)
>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
>     raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt

Error log contains the message:

if test -d /tmp/lilypond-autobuild/.git  ; then \
        cd /tmp/lilypond-autobuild ; \
        BR=`LANG=c git branch | grep "^\*" | sed -e "s|^* *||"` ; \
        HD=`git rev-parse --verify HEAD` ; \
        FP=`git merge-base --octopus master HEAD` ; \
        echo "    BRANCH: $BR" ; \
        echo "      HEAD: $HD" ; \
        if [ ! -z $FP ]; then  \
                echo "MERGE_BASE: $FP" ; \
                echo -e '\n   HISTORY:\n   ========\n' ; \
                git log --pretty=format:"      HASH: %H%n   SUBJECT: %s%n" $FP~1..HEAD ; \
        else \
                echo "MERGE_BASE: unknown" ; \
                echo -e '\n   HISTORY:\n   ========\n' ; \
                git log --max-count=10 --pretty=format:"      HASH: %H%nSUBJECT: %s%n" ; \
        fi ; \
        echo "" ; \
fi > ./out-test/tree.gittxt
fatal: Not a valid object name master

Apparently, the patch from
commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
Author: Knut Petersen <[hidden email]>
Date:   Sun Jul 7 13:16:05 2019 +0200

    Optimize tree.gittxt messages
   
    We display BRANCH, HEAD, MERGE-POINT
    and HISTORY fom merge-point to HEAD.
   
    If we do not find a merge-point we
    display the last ten commits if this
    is possible.

relies on the existence of a local (rather than upstream) branch
"master", not a good idea.  I am backing out this commit from staging:
it needs to get fixed.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
David Kastrup <[hidden email]> writes:

> [hidden email] writes:
>
>> 14:39:40 (UTC) Begin LilyPond compile, previous commit at 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:39:51 Merged staging, now at: 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:39:52 Success: ./autogen.sh --noconfigure
>> 14:40:08 Success: /tmp/lilypond-autobuild/configure --enable-checking
>> 14:40:11 Success: nice make clean
>> 14:44:20 Success: nice make -j9 CPU_COUNT=9
>> 14:47:28 *** FAILED BUILD ***
>> nice make test -j9 CPU_COUNT=9
>> Previous good commit: 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>> Current broken commit: 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:47:28 *** FAILED STEP ***
>> merge from staging
>> Failed runner: nice make test -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>> 14:47:28 Traceback (most recent call last):
>>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
>>     self.build (issue_id=issue_id)
>>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
>>     issue_id)
>>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
>>     raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
>> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>
> Error log contains the message:
>
> if test -d /tmp/lilypond-autobuild/.git  ; then \
>         cd /tmp/lilypond-autobuild ; \
>         BR=`LANG=c git branch | grep "^\*" | sed -e "s|^* *||"` ; \
>         HD=`git rev-parse --verify HEAD` ; \
>         FP=`git merge-base --octopus master HEAD` ; \
>         echo "    BRANCH: $BR" ; \
>         echo "      HEAD: $HD" ; \
>         if [ ! -z $FP ]; then  \
>                 echo "MERGE_BASE: $FP" ; \
>                 echo -e '\n   HISTORY:\n   ========\n' ; \
>                 git log --pretty=format:"      HASH: %H%n   SUBJECT: %s%n" $FP~1..HEAD ; \
>         else \
>                 echo "MERGE_BASE: unknown" ; \
>                 echo -e '\n   HISTORY:\n   ========\n' ; \
>                 git log --max-count=10 --pretty=format:"      HASH: %H%nSUBJECT: %s%n" ; \
>         fi ; \
>         echo "" ; \
> fi > ./out-test/tree.gittxt
> fatal: Not a valid object name master
>
> Apparently, the patch from
> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
> Author: Knut Petersen <[hidden email]>
> Date:   Sun Jul 7 13:16:05 2019 +0200
>
>     Optimize tree.gittxt messages
>    
>     We display BRANCH, HEAD, MERGE-POINT
>     and HISTORY fom merge-point to HEAD.
>    
>     If we do not find a merge-point we
>     display the last ten commits if this
>     is possible.
>
> relies on the existence of a local (rather than upstream) branch
> "master", not a good idea.  I am backing out this commit from staging:
> it needs to get fixed.

Someone or some patchy happening to have a local master branch (a bad
idea since absolutely no development should happen in a local master
branch in our setup) already pushed that commit to staging.
Consequentially, I had to push a revert to staging and hope I'll get it
through without manually tampering with master.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
David Kastrup <[hidden email]> writes:

> David Kastrup <[hidden email]> writes:
>
>> fatal: Not a valid object name master
>>
>> Apparently, the patch from
>> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>> Author: Knut Petersen <[hidden email]>
>> Date:   Sun Jul 7 13:16:05 2019 +0200
>>
>>     Optimize tree.gittxt messages
>>    
>>     We display BRANCH, HEAD, MERGE-POINT
>>     and HISTORY fom merge-point to HEAD.
>>    
>>     If we do not find a merge-point we
>>     display the last ten commits if this
>>     is possible.
>>
>> relies on the existence of a local (rather than upstream) branch
>> "master", not a good idea.  I am backing out this commit from staging:
>> it needs to get fixed.
>
> Someone or some patchy happening to have a local master branch (a bad
> idea since absolutely no development should happen in a local master
> branch in our setup) already pushed that commit to staging.

I mean, to master.  Pushing to staging was very much the correct step to
take in the life of the patch.

> Consequentially, I had to push a revert to staging and hope I'll get it
> through without manually tampering with master.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

James Lowe-3
Hello,

On 26/07/2019 16:13, David Kastrup wrote:

> David Kastrup <[hidden email]> writes:
>
>> David Kastrup <[hidden email]> writes:
>>
>>> fatal: Not a valid object name master
>>>
>>> Apparently, the patch from
>>> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>>> Author: Knut Petersen <[hidden email]>
>>> Date:   Sun Jul 7 13:16:05 2019 +0200
>>>
>>>      Optimize tree.gittxt messages
>>>      
>>>      We display BRANCH, HEAD, MERGE-POINT
>>>      and HISTORY fom merge-point to HEAD.
>>>      
>>>      If we do not find a merge-point we
>>>      display the last ten commits if this
>>>      is possible.
>>>
>>> relies on the existence of a local (rather than upstream) branch
>>> "master", not a good idea.  I am backing out this commit from staging:
>>> it needs to get fixed.
>> Someone or some patchy happening to have a local master branch (a bad
>> idea since absolutely no development should happen in a local master
>> branch in our setup) already pushed that commit to staging.
> I mean, to master.  Pushing to staging was very much the correct step to
> take in the life of the patch.
>
>> Consequentially, I had to push a revert to staging and hope I'll get it
>> through without manually tampering with master.

I personally closed the sourceforge ticket with the commit ID etc.

--snip--

pkx166h <https://sourceforge.net/u/lilypond-pkx/> - /3 days ago /
<https://sourceforge.net/p/testlilyissues/issues/5534/#d5a7>

Optimize tree.gittxt messages master staging
author  Knut Petersen <[hidden email]>
     Sun, 7 Jul 2019 12:16:05 +0100 (13:16 +0200)
committer   Knut Petersen <[hidden email]>
     Mon, 22 Jul 2019 10:04:40 +0100 (11:04 +0200)
commit  7583351fbf2f08a4d1f3f0b075fe8b691adc0b95

--snip--

However looking at the date stamps of the logs of my patchy runs - the
patchy scrits generate text files for each run - I ran one on the 25th
(pushing Urs trivial checkin) and then before that on the 17th, which
was for Knut's previous fix (and I think included Werner's).

So there is another patchy pushing stuff as Knut's 'failed' commit was
in between those times.

Unless Knut is also running patchy now that he has commit access (and
perhaps didn't have a clean master?).

(I don't want to cast aspersions, but it might be a genuine mistake if
it was Knut). Knut?

James

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
James <[hidden email]> writes:

> Hello,
>
> On 26/07/2019 16:13, David Kastrup wrote:
>> David Kastrup <[hidden email]> writes:
>>
>>> David Kastrup <[hidden email]> writes:
>>>
>>>> fatal: Not a valid object name master
>>>>
>>>> Apparently, the patch from
>>>> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>>>> Author: Knut Petersen <[hidden email]>
>>>> Date:   Sun Jul 7 13:16:05 2019 +0200
>>>>
>>>>      Optimize tree.gittxt messages
>>>>           We display BRANCH, HEAD, MERGE-POINT
>>>>      and HISTORY fom merge-point to HEAD.
>>>>           If we do not find a merge-point we
>>>>      display the last ten commits if this
>>>>      is possible.
>>>>
>>>> relies on the existence of a local (rather than upstream) branch
>>>> "master", not a good idea.  I am backing out this commit from staging:
>>>> it needs to get fixed.
>>> Someone or some patchy happening to have a local master branch (a bad
>>> idea since absolutely no development should happen in a local master
>>> branch in our setup) already pushed that commit to staging.
>> I mean, to master.  Pushing to staging was very much the correct step to
>> take in the life of the patch.
>>
>>> Consequentially, I had to push a revert to staging and hope I'll get it
>>> through without manually tampering with master.
>
> I personally closed the sourceforge ticket with the commit ID etc.
>
> --snip--
>
> pkx166h <https://sourceforge.net/u/lilypond-pkx/> - /3 days ago /
> <https://sourceforge.net/p/testlilyissues/issues/5534/#d5a7>
>
> Optimize tree.gittxt messages master staging
> author  Knut Petersen <[hidden email]>
>     Sun, 7 Jul 2019 12:16:05 +0100 (13:16 +0200)
> committer   Knut Petersen <[hidden email]>
>     Mon, 22 Jul 2019 10:04:40 +0100 (11:04 +0200)
> commit  7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>
> --snip--
>
> However looking at the date stamps of the logs of my patchy runs - the
> patchy scrits generate text files for each run - I ran one on the 25th
> (pushing Urs trivial checkin) and then before that on the 17th, which
> was for Knut's previous fix (and I think included Werner's).
>
> So there is another patchy pushing stuff as Knut's 'failed' commit was
> in between those times.

I run Patchy when I notice something went to staging.  Due to its cost,
I tend to abort it when I discover someone else pushing before me.

So it would appear that your repository (and probably that of Knut) have
a local master branch which would mask that the patch in question does
not produce output relative to the origin repository and thus produces
stuff that is not reducible.  A local master branch tends to be a bad
idea (though not as bad as a local staging branch) since you don't want
to collect changes of your own on it.

> Unless Knut is also running patchy now that he has commit access (and
> perhaps didn't have a clean master?).
>
> (I don't want to cast aspersions, but it might be a genuine mistake if
> it was Knut). Knut?

I rather doubt that it was Knut since I mentioned the procedures to him
right now and you said that you pushed the patch in question anyway (so
it's very unlikely that he'd run the patchy subsequently responsible for
promoting it to master).

The more likely version is that your repository, having a local master
branch, failed figuring out that the patch was problematic and promoted
it to master.  And my patchy version, running at some later date to push
an unrelated patch, got tripped up by the change that had entered master
because of your Patchy not tripping over the behavior that my Patchy got
stuck on.

And my first mails were based on me missing that the problematic patch
in master had already been there for a day or two.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Knut Petersen
On 26.07.19 20:36, David Kastrup wrote:

>
>> Unless Knut is also running patchy now that he has commit access (and
>> perhaps didn't have a clean master?).
>>
>> (I don't want to cast aspersions, but it might be a genuine mistake if
>> it was Knut). Knut?
> I rather doubt that it was Knut since I mentioned the procedures to him
> right now and you said that you pushed the patch in question anyway (so
> it's very unlikely that he'd run the patchy subsequently responsible for
> promoting it to master).
I never used patchy. According to my memories and according to my logs
pushing the commits to staging was done right and successful.

But yes, there is a local branch master on my system. I never thought that
there is a clone of the lilypond repository without a local master as

    git clone git://git.sv.gnu.org/lilypond.git


clones the repository and checks out 'master'. Sorry for the mess.

It's clear that 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95 needs
to be fixed.

What happened to the musicxml2ly patch? It vanished from staging.
Shall I push it again?

Knut
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Knut Petersen <[hidden email]> writes:

> On 26.07.19 20:36, David Kastrup wrote:
>>
>>> Unless Knut is also running patchy now that he has commit access (and
>>> perhaps didn't have a clean master?).
>>>
>>> (I don't want to cast aspersions, but it might be a genuine mistake if
>>> it was Knut). Knut?
>> I rather doubt that it was Knut since I mentioned the procedures to him
>> right now and you said that you pushed the patch in question anyway (so
>> it's very unlikely that he'd run the patchy subsequently responsible for
>> promoting it to master).
> I never used patchy. According to my memories and according to my logs
> pushing the commits to staging was done right and successful.
>
> But yes, there is a local branch master on my system. I never thought that
> there is a clone of the lilypond repository without a local master as
>
>    git clone git://git.sv.gnu.org/lilypond.git
>
>
> clones the repository and checks out 'master'. Sorry for the mess.
>
> It's clear that 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95 needs
> to be fixed.
>
> What happened to the musicxml2ly patch? It vanished from staging.
> Shall I push it again?

It didn't pass patchy testing on my computer with failures in the
musicxml files.  So it appears to have a problem with, uh, Python
2.7.16+ (according to python --version on my current Ubuntu).  If you
need more pointers, I can try getting useful logs.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Knut Petersen
On 27.07.19 07:56, David Kastrup wrote:
>
>> What happened to the musicxml2ly patch? It vanished from staging.
>> Shall I push it again?
> It didn't pass patchy testing on my computer with failures in the
> musicxml files.  So it appears to have a problem with, uh, Python
> 2.7.16+ (according to python --version on my current Ubuntu).  If you
> need more pointers, I can try getting useful logs.


Yes, that would be very helpful. Before announcing that I thought that the patch was ready it passed a full GUB build on my system and the code processed all musicxml from the lilypond sources correctly with both the GUB-generated python 2.4.5 and the system's (opensuse tumbleweed) python 2.7.16.

The relevant log file and the *.ly files generated from the xml sources would be of interest.

What distribution do you use? Please your /etc/os-release.

Knut


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Knut Petersen <[hidden email]> writes:

> On 27.07.19 07:56, David Kastrup wrote:
>>
>>> What happened to the musicxml2ly patch? It vanished from staging.
>>> Shall I push it again?
>> It didn't pass patchy testing on my computer with failures in the
>> musicxml files.  So it appears to have a problem with, uh, Python
>> 2.7.16+ (according to python --version on my current Ubuntu).  If you
>> need more pointers, I can try getting useful logs.
>
>
> Yes, that would be very helpful. Before announcing that I thought that
> the patch was ready it passed a full GUB build on my system and the
> code processed all musicxml from the lilypond sources correctly with
> both the GUB-generated python 2.4.5 and the system's (opensuse
> tumbleweed) python 2.7.16.
>
> The relevant log file and the *.ly files generated from the xml
> sources would be of interest.
Converting MusicXML file `74a-FiguredBass.xml'...

Converting MusicXML file `75a-AccordionRegistrations.xml'...

Converting MusicXML file `90a-Compressed-MusicXML.mxl'...

Converting MusicXML file `99a-Sibelius5-IgnoreBeaming.xml'...

Converting MusicXML file `99b-Lyrics-BeamsMelismata-IgnoreBeams.xml'...

Writing snippets...
Processing...
Processing /usr/local/tmp/lilypond/out/lybook-testdb/snippet-names-9124213700985165589.ly
command failed: /usr/local/tmp/lilypond/out/bin/lilypond \
        -I .  -dbackend=eps --formats=ps  -dseparate-log-files -dinclude-eps-fonts -dgs-load-fonts --header=texidoc -I /usr/local/tmp/lilypond/Documentation/included/ -ddump-profile -dcheck-internal-types -ddump-signatures -danti-alias-factor=1 -dfont-export-dir=/usr/local/tmp/lilypond/out-fonts -O TeX-GS -I  "./"  -I  "/usr/local/tmp/lilypond/input/regression/musicxml"  -I  "/usr/local/tmp/lilypond/input/regression/musicxml" --formats=eps  -deps-box-padding=3.000000  -dread-file-list -dno-strip-output-dir  "/usr/local/tmp/lilypond/out/lybook-testdb/snippet-names-9124213700985165589.ly"
Child returned 1
Error ignored by lilylib
Error trapped by lilypond-book

Please see /usr/local/tmp/lilypond/out/lybook-testdb/snippet-names-9124213700985165589.log

make[2]: *** [../../../make/ly-rules.make:42: out-test/collated-files.texi] Error 1
make[2]: Leaving directory '/usr/local/tmp/lilypond/input/regression/musicxml'
make[1]: *** [../../../make/lysdoc-targets.make:14: local-test] Error 2
make[1]: Leaving directory '/usr/local/tmp/lilypond/input/regression/musicxml'
make: *** [GNUmakefile:314: test] Error 2

dak@lola:/usr/local/tmp/lilypond$ grep sourcefilename `grep -L systems.texi out/lybook-testdb/*/*log|sed s/log/ly/g`
out/lybook-testdb/02/lily-9590f87a.ly:\sourcefilename "46g-PickupMeasure-Chordnames-FiguredBass.xml"
out/lybook-testdb/bf/lily-5968767c.ly:\sourcefilename "71f-AllChordTypes.xml"
out/lybook-testdb/cf/lily-aefcd7fa.ly:\sourcefilename "71d-ChordsFrets-Multistaff.xml"
out/lybook-testdb/d1/lily-4604f705.ly:\sourcefilename "71g-MultipleChordnames.xml"
out/lybook-testdb/e9/lily-5da7485a.ly:\sourcefilename "71a-Chordnames.xml"
out/lybook-testdb/f7/lily-4ea110e1.ly:\sourcefilename "71c-ChordsFrets.xml"


%% Generated by lilypond-book.py
%% Options: [exampleindent=10.16\mm,indent=0\mm,line-width=160\mm]
\include "lilypond-book-preamble.ly"


% ****************************************************************
% Start cut-&-pastable-section
% ****************************************************************



\paper {
  indent = 0\mm
  line-width = 160\mm
  % offset the left padding, also add 1mm as lilypond creates cropped
  % images with a little space on the right
  line-width = #(- line-width (* mm  3.000000) (* mm 1))
}

\layout {
 
}





% ****************************************************************
% ly snippet:
% ****************************************************************
\sourcefilename "46g-PickupMeasure-Chordnames-FiguredBass.xml"
\sourcefileline 0
\version "2.21.0"
% automatically converted by musicxml2ly from -
\pointAndClickOff

\header {
    texidoc =
    "Pickup measure with chord names
           and figured bass."
    }

\layout {
    \context { \Score
        autoBeaming = ##f
        }
    }
PartPOneVoiceOne =  \relative c'' {
    \key c \major \numericTimeSignature\time 4/4 \partial 4 c8 c8 | % 1
    c,4 c4 c4 c4 }

PartPOneVoiceOneChords =  \chordmode {
    \partial 4 :5 s8 | % 1
    :5 s4 s4 }

PartPOneVoiceOneFiguredBass =  \figuremode {
    \partial 4 <3>8 s8 | % 1
    <3>8 s8 s4 s4 }


% The score definition
\score {
    <<
       
        \context ChordNames = "PartPOneVoiceOneChords" { \PartPOneVoiceOneChords}
        \new Staff
        <<
           
            \context Staff <<
                \mergeDifferentlyDottedOn\mergeDifferentlyHeadedOn
                \context Voice = "PartPOneVoiceOne" {  \PartPOneVoiceOne }
                \context FiguredBass = "PartPOneVoiceOneFiguredBass" \PartPOneVoiceOneFiguredBass
                >>
            >>
       
        >>
    \layout {}
    % To create MIDI output, uncomment the following line:
    %  \midi {\tempo 4 = 100 }
    }




% ****************************************************************
% end ly snippet
% ****************************************************************


dak@lola:/usr/local/tmp/lilypond$ out/bin/lilypond out/lybook-testdb/02/lily-9590f87a.ly
GNU LilyPond 2.21.0
Processing `out/lybook-testdb/02/lily-9590f87a.ly'
Parsing...
Renaming input to: `46g-PickupMeasure-Chordnames-FiguredBass.xml'
46g-PickupMeasure-Chordnames-FiguredBass.xml:21:16: error: syntax error, unexpected :
    \partial 4
               :5 s8 | % 1
46g-PickupMeasure-Chordnames-FiguredBass.xml:21:17: error: not a duration
    \partial 4 :
                5 s8 | % 1
46g-PickupMeasure-Chordnames-FiguredBass.xml:22:5: error: syntax error, unexpected :
   
    :5 s4 s4 }
46g-PickupMeasure-Chordnames-FiguredBass.xml:22:6: error: not a duration
    :
     5 s4 s4 }
46g-PickupMeasure-Chordnames-FiguredBass.xml:31:5: error: errors found, ignoring music expression
   
    <<
fatal error: failed files: "out/lybook-testdb/02/lily-9590f87a.ly"
dak@lola:/usr/local/tmp/lilypond$

> What distribution do you use? Please your /etc/os-release.

NAME="Ubuntu"
VERSION="19.10 (Eoan Ermine)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu Eoan Ermine (development branch)"
VERSION_ID="19.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=eoan
UBUNTU_CODENAME=eoan

dak@lola:/usr/local/tmp/lilypond$ dpkg -S /usr/bin/python
python-minimal: /usr/bin/python
dak@lola:/usr/local/tmp/lilypond$ dpkg -l python-minimal
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-======================================
ii  python-minimal 2.7.16-1     amd64        minimal subset of the Python2 language


--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

James Lowe-3
In reply to this post by David Kastrup

On 26/07/2019 19:36, David Kastrup wrote:

> ...
> I run Patchy when I notice something went to staging.  Due to its cost,
> I tend to abort it when I discover someone else pushing before me.
>
> So it would appear that your repository (and probably that of Knut) have
> a local master branch which would mask that the patch in question does
> not produce output relative to the origin repository and thus produces
> stuff that is not reducible.  A local master branch tends to be a bad
> idea (though not as bad as a local staging branch) since you don't want
> to collect changes of your own on it.

However the patchy scripts set up a local master

e.g. If I manually delete my local master and then run the patchy scripts:

 > Branch 'master' set up to track remote branch 'master' from 'origin'.
 > Switched to a new branch 'master'

(or is that not what you are talking about?)

My workflow is that I always make sure that dev/local_working (where I
do my own changes before creating patches), local staging and local
master are always 'in sync' before I run patchy and that staging is cleaned.

It's no different than what I have always done.

So I wonder why the tests passed and my own patchy merge passed but
yours failed?

I am just worried that the veracity of my patch testing is not good enough


regards

James

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
James <[hidden email]> writes:

> On 26/07/2019 19:36, David Kastrup wrote:
>> ...
>> I run Patchy when I notice something went to staging.  Due to its cost,
>> I tend to abort it when I discover someone else pushing before me.
>>
>> So it would appear that your repository (and probably that of Knut) have
>> a local master branch which would mask that the patch in question does
>> not produce output relative to the origin repository and thus produces
>> stuff that is not reducible.  A local master branch tends to be a bad
>> idea (though not as bad as a local staging branch) since you don't want
>> to collect changes of your own on it.
>
> However the patchy scripts set up a local master
>
> e.g. If I manually delete my local master and then run the patchy scripts:
>
>> Branch 'master' set up to track remote branch 'master' from 'origin'.
>> Switched to a new branch 'master'
>
> (or is that not what you are talking about?)

It is, but that does not happen in my repository when running
lilypond-patchy-staging.py .  Since there is no point in maintaining a
local master potentially differing from upstream in the testing scripts,
I wonder what script would be responsible here.

> My workflow is that I always make sure that dev/local_working (where I
> do my own changes before creating patches), local staging and local
> master are always 'in sync' before I run patchy and that staging is
> cleaned.
>
> It's no different than what I have always done.
>
> So I wonder why the tests passed and my own patchy merge passed but
> yours failed?

My patchy-staging test does not create a local master and I don't
maintain one of my own.  I wonder why it would be different from yours.

> I am just worried that the veracity of my patch testing is not good
> enough

My lilypond-extra is up to date with two patches on top (that likely
should at some time be pushed):

commit c8c317eed3e774fb73132e48071ebd14bdda1b88 (HEAD -> master)
Author: David Kastrup <[hidden email]>
Date:   Tue May 19 10:21:13 2015 +0200

    Replace --disable-optimising with the faster --enable-checking

commit 6d784e9a2c5e7f0f1baf6cd500459504be51826e
Author: David Kastrup <[hidden email]>
Date:   Tue Feb 12 11:11:57 2013 +0100

    Use printf rather than echo for result script to avoid interpreted backslashes

Neither of those would make a difference in that regard.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

James Lowe-3
Hello,

On 27/07/2019 10:10, David Kastrup wrote:

> James <[hidden email]> writes:
>
>> On 26/07/2019 19:36, David Kastrup wrote:
>>> ...
>>> I run Patchy when I notice something went to staging.  Due to its cost,
>>> I tend to abort it when I discover someone else pushing before me.
>>>
>>> So it would appear that your repository (and probably that of Knut) have
>>> a local master branch which would mask that the patch in question does
>>> not produce output relative to the origin repository and thus produces
>>> stuff that is not reducible.  A local master branch tends to be a bad
>>> idea (though not as bad as a local staging branch) since you don't want
>>> to collect changes of your own on it.
>> However the patchy scripts set up a local master
>>
>> e.g. If I manually delete my local master and then run the patchy scripts:
>>
>>> Branch 'master' set up to track remote branch 'master' from 'origin'.
>>> Switched to a new branch 'master'
>> (or is that not what you are talking about?)
> It is, but that does not happen in my repository when running
> lilypond-patchy-staging.py .  Since there is no point in maintaining a
> local master potentially differing from upstream in the testing scripts,
> I wonder what script would be responsible here.

I don't think it is any script per se, I used to use Lily-git (which
fetches master and staging and sets up dev/local_working.

So I've always had a local master.

Also, I test patches against current master (not staging) so I'd need a
local master then too right?

i.e

checkout master, run make, make test-basline, apply patch etc etc.

>
>> My workflow is that I always make sure that dev/local_working (where I
>> do my own changes before creating patches), local staging and local
>> master are always 'in sync' before I run patchy and that staging is
>> cleaned.
>>
>> It's no different than what I have always done.
>>
>> So I wonder why the tests passed and my own patchy merge passed but
>> yours failed?
> My patchy-staging test does not create a local master and I don't
> maintain one of my own.  I wonder why it would be different from yours.

I don't run a script to test patches - the script 'broke' when we moved
from Google to Sourceforge, so I just test patches 'manually' (out of
tree) but I do make sure my local master is reset 'hard' (so to speak)
before I test things.

Patchy-merge scripts are the ones I have always used

and it creates a 'lock' branch test-master-lock (I think as a kind of
simple failsafe if a user ends up running two or more instances or a
previous instance failed to complete or clean up properly).

I use the script from lilypond-extra/patches/(compile_lilypond_test).


James



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
James <[hidden email]> writes:

> Hello,
>
> On 27/07/2019 10:10, David Kastrup wrote:
>> James <[hidden email]> writes:
>>
>>> On 26/07/2019 19:36, David Kastrup wrote:
>>>> ...
>>>> I run Patchy when I notice something went to staging.  Due to its cost,
>>>> I tend to abort it when I discover someone else pushing before me.
>>>>
>>>> So it would appear that your repository (and probably that of Knut) have
>>>> a local master branch which would mask that the patch in question does
>>>> not produce output relative to the origin repository and thus produces
>>>> stuff that is not reducible.  A local master branch tends to be a bad
>>>> idea (though not as bad as a local staging branch) since you don't want
>>>> to collect changes of your own on it.
>>> However the patchy scripts set up a local master
>>>
>>> e.g. If I manually delete my local master and then run the patchy scripts:
>>>
>>>> Branch 'master' set up to track remote branch 'master' from 'origin'.
>>>> Switched to a new branch 'master'
>>> (or is that not what you are talking about?)
>> It is, but that does not happen in my repository when running
>> lilypond-patchy-staging.py .  Since there is no point in maintaining a
>> local master potentially differing from upstream in the testing scripts,
>> I wonder what script would be responsible here.
>
> I don't think it is any script per se, I used to use Lily-git (which
> fetches master and staging and sets up dev/local_working.
>
> So I've always had a local master.
>
> Also, I test patches against current master (not staging) so I'd need
> a local master then too right?
>
> i.e
>
> checkout master, run make, make test-basline, apply patch etc etc.

You don't need a local master for that.  checkout origin or checkout
origin/master does not create a local branch but just works from an
ephemeral commit.

> I don't run a script to test patches - the script 'broke' when we
> moved from Google to Sourceforge, so I just test patches 'manually'
> (out of tree) but I do make sure my local master is reset 'hard' (so
> to speak) before I test things.

You'll need to reset the work directory in any case (but a new checkout
should cater for that), but branch maintenance is not really necessary.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Knut Petersen
In reply to this post by David Kastrup
Hi David!

Thank you for the information you provided. Something is really broken,
but after quite some time of debugging, I'm beginning to wonder if it really
is my patch / system or if it might be that origin/master is broken after all.

Could you please verify if  (after adapting the arguments to configure in
line 6) executing the following commands in your local lilypond repository
succeeds? Be aware that there is a 'git clean' command, so save your work first!

    git clean -dfx
    git checkout origin/master
    ./autogen.sh --noconfigure
    mkdir -p build
    cd build
    ../configure --prefix=<path_to_target_dir> --with-urwotf-dir=<path_to_urw-core35-fonts_dir>
    make -j 11 CPU_COUNT=11 all
    make -j 11 CPU_COUNT=11 test-baseline

Making test-baseline really should succeed - on my system it does _not_ succeed
with the current origin/master. If making test-baseline does not succeed: Does it
succeed with my patch (1c51a616e289fffb918942c8f1e189ab50809157)?

Is there a safe way to execute a local patchy test?

Knut
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Knut Petersen <[hidden email]> writes:

> Hi David!
>
> Thank you for the information you provided. Something is really broken,
> but after quite some time of debugging, I'm beginning to wonder if it really
> is my patch / system or if it might be that origin/master is broken after all.
>
> Could you please verify if  (after adapting the arguments to configure in
> line 6) executing the following commands in your local lilypond repository
> succeeds? Be aware that there is a 'git clean' command, so save your work first!
>
>    git clean -dfx

I am not going to git-clean on my current repository/workdirectory since
there is too much temporary stuff in there I might still need.  I will
create a separate clone.

>    git checkout origin/master
>    ./autogen.sh --noconfigure
>    mkdir -p build
>    cd build
>    ../configure --prefix=<path_to_target_dir>
> --with-urwotf-dir=<path_to_urw-core35-fonts_dir>

I don't have urwotf fonts but doubt that would be related to the
musicxml2ly issues.

>    make -j 11 CPU_COUNT=11 all
>    make -j 11 CPU_COUNT=11 test-baseline
>
> Making test-baseline really should succeed - on my system it does _not_ succeed
> with the current origin/master. If making test-baseline does not succeed: Does it
> succeed with my patch (1c51a616e289fffb918942c8f1e189ab50809157)?
>
> Is there a safe way to execute a local patchy test?

Patchy does nothing you cannot do manually.  I don't remember offhand
whether it builds in-place or out-of-place.  lilypond-patchy-staging
does not work with "make check" or "make test-baseline": it merely does
make all, make test, and make doc .  I haven't created a test-baseline
for myself in quite a bit of time.  I'll do that first in my local setup
to check whether that still works.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
David Kastrup <[hidden email]> writes:

> Knut Petersen <[hidden email]> writes:
>
>> Hi David!
>>
>> Thank you for the information you provided. Something is really broken,
>> but after quite some time of debugging, I'm beginning to wonder if it really
>> is my patch / system or if it might be that origin/master is broken after all.
>>
>> Could you please verify if  (after adapting the arguments to configure in
>> line 6) executing the following commands in your local lilypond repository
>> succeeds? Be aware that there is a 'git clean' command, so save your work first!
>>
>>    git clean -dfx
>
> I am not going to git-clean on my current repository/workdirectory since
> there is too much temporary stuff in there I might still need.  I will
> create a separate clone.
>
>>    git checkout origin/master
>>    ./autogen.sh --noconfigure
>>    mkdir -p build
>>    cd build
>>    ../configure --prefix=<path_to_target_dir>
>> --with-urwotf-dir=<path_to_urw-core35-fonts_dir>
>
> I don't have urwotf fonts but doubt that would be related to the
> musicxml2ly issues.
>
>>    make -j 11 CPU_COUNT=11 all
>>    make -j 11 CPU_COUNT=11 test-baseline
>>
>> Making test-baseline really should succeed - on my system it does _not_ succeed
>> with the current origin/master. If making test-baseline does not
>> succeed: Does it
>> succeed with my patch (1c51a616e289fffb918942c8f1e189ab50809157)?
>>
>> Is there a safe way to execute a local patchy test?
>
> Patchy does nothing you cannot do manually.  I don't remember offhand
> whether it builds in-place or out-of-place.  lilypond-patchy-staging
> does not work with "make check" or "make test-baseline": it merely does
> make all, make test, and make doc .  I haven't created a test-baseline
> for myself in quite a bit of time.  I'll do that first in my local setup
> to check whether that still works.

And here are the results from a freshly cloned tree: with your patch,
test-baseline fails.  Without it, it succeeds.

The musicxml error clearly is due to the way you rewrote chord mode
output.  Either you forgot to cater for some case (in which case it
would be surprising that it succeeds at your site), or the committed
patch does not contain all the changes you did at your site (have you
checked cherry-picking the version pushed to staging?).  Or our
environment differs in some crucial detail.  Or, given the rather bland
symptoms, the build procedures on your and/or my site pick up part of
locally installed files rather than just the build tree, and the
corresponding mismatch of the code (more than one Python file is changed
by the patch) leads to the problematic output.

Would any log files help?  I can rerun make test (both successfully and
unsuccessfully) with redirected log files and probably also not use
multithreading in order to give comparable log files.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Knut Petersen
On 29.07.19 16:27, David Kastrup wrote:
> And here are the results from a freshly cloned tree: with your patch,
> test-baseline fails.  Without it, it succeeds.

Thanks. The other way round here.

> Would any log files help?  I can rerun make test (both successfully and
> unsuccessfully) with redirected log files and probably also not use
> multithreading in order to give comparable log files.
Unfortunately the logs don't show which parts of the python etc. are used.
I'll do some further tests and strace the whole 'make test-baseline' process.
Somewhere in the strace logs will be the answer.

Knut

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Knut Petersen <[hidden email]> writes:

> On 29.07.19 16:27, David Kastrup wrote:
>> And here are the results from a freshly cloned tree: with your patch,
>> test-baseline fails.  Without it, it succeeds.
>
> Thanks. The other way round here.
>
>> Would any log files help?  I can rerun make test (both successfully and
>> unsuccessfully) with redirected log files and probably also not use
>> multithreading in order to give comparable log files.
> Unfortunately the logs don't show which parts of the python etc. are used.
> I'll do some further tests and strace the whole 'make test-baseline' process.
> Somewhere in the strace logs will be the answer.

For whatever it may be worth: outside of running the build scripts I
have

dak@lola:/usr/local/tmp/lilypond2/build$ which musicxml2ly
/usr/local/bin/musicxml2ly
dak@lola:/usr/local/tmp/lilypond2/build$ echo $PATH
/home/dak/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

That variant of musicxml2ly would be of some 2.21.0 leadup variety.  If
you have anything derived from your patch/testing there, this could be
involved with the difference we are (but should not be) seeing.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
In reply to this post by Knut Petersen
Knut Petersen <[hidden email]> writes:

> On 29.07.19 16:27, David Kastrup wrote:
>> And here are the results from a freshly cloned tree: with your patch,
>> test-baseline fails.  Without it, it succeeds.
>
> Thanks. The other way round here.
>
>> Would any log files help?  I can rerun make test (both successfully and
>> unsuccessfully) with redirected log files and probably also not use
>> multithreading in order to give comparable log files.
> Unfortunately the logs don't show which parts of the python etc. are used.
> I'll do some further tests and strace the whole 'make test-baseline' process.
> Somewhere in the strace logs will be the answer.

Well, it is rather obvious that you should not be seeing failure with
unchanged master (assuming that you have some reasonably current Python
on your system) and I should not be seeing failure with your patch
(assuming that it tests out on your system: the symptoms are just too
clear to seem dependent on Python version).  So it's likely that some
preinstalled part (assuming both of us worked from clean trees) creeps
into both our operations.  That would be more likely than not a
preexisting problem not caused by your patch but we would still better
fix it before it causes more headaches.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
12