subject:"Patchy email"

Am Sonntag, den 19.04.2020, 18:20 + schrieb Valentin Villenave:
> On 4/19/20, David Kastrup <
> d...@gnu.org
> > wrote:
> > mkstemp! does not generate a string.  It overwrites an existing string
> > in-place, and that's bad news for a literal string.
> 
> Yes, it overwrite the string, opens a port, then I read the
> port-filename which should be an _other_ string object, shouldn’t it?
> (sigh -- _none_ of this would happen if they hadn’t decided to remove
> tmpnam, or if they had bothered to make tmpnam behave correctly and
> respect TMPDIR, or if they had a mkdtemp! function.)

Hm, where's that deprecation notice? The web page [1] only says you
have to be careful in case of a malicious attacker. But we're talking
about a test here, so I don't think this applies.

1: 
https://www.gnu.org/software/guile/manual/html_node/File-System.html#index-tmpnam


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

Re: Patchy email

Am Sonntag, den 19.04.2020, 20:57 +0200 schrieb David Kastrup:
> Jonas Hahnfeld  writes:
> > So I guess the fix is to delete the (temporary) directory and all
> > contained files? And maybe putting it under /tmp?
> > 
> > Oh, and ignore my comment that I had tested this with Guile 2.2. Looks
> > like I didn't (at least not properly).
> 
> It may depend on how the literal string enters Guile whether the R/O
> detection triggers.

For the record, it's triggering something:
 $ ./out/bin/lilypond ../src/input/regression/font-name-add-files.ly 
GNU LilyPond 2.21.1
Processing `../src/input/regression/font-name-add-files.ly'
Parsing...
fatal error: failed adding font file: dummyfont-VfhPDN-font.otf

But that's probably third after the uuid file and moving to /tmp.

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

Re: Patchy email

Jonas Hahnfeld  writes:

> Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup:
>> David Kastrup <
>> d...@gnu.org
>> > writes:
>> 
>> > David Kastrup <
>> > d...@gnu.org
>> > > writes:
>> > 
>> > > David Kastrup <
>> > > d...@gnu.org
>> > > > writes:
>> > > 
>> > > > Valentin Villenave <
>> > > > valen...@villenave.net
>> > > > > writes:
>> > > > 
>> > > > > On 4/19/20, David Kastrup <
>> > > > > d...@gnu.org
>> > > > > > wrote:
>> > > > > > Note that the delete-file instructions are executed while the book 
>> > > > > > is
>> > > > > > being read in while markup is typeset when the books are being 
>> > > > > > processed
>> > > > > > at the end of the input file.
>> > > > > 
>> > > > > Yes, it looked completely bonkers to me as well, until I realized it 
>> > > > > worked :-)
>> > > > > 
>> > > > > > No idea whether the fonts made it into
>> > > > > > LilyPond at that point of time, or how happy LilyPond is with them
>> > > > > > appearing.
>> > > > > 
>> > > > > No, because at this point the first \book has already been processed,
>> > > > > and even GS should already be invoked. That’s the whole point of
>> > > > > putting that stuff inside another \book.
>> > > > 
>> > > > There is no point in putting the deletion of files "inside another
>> > > > \book" since it is not being executed when the book is typeset but when
>> > > > the book is read in.
>> > > > 
>> > > > > > There may well be race conditions here.
>> > > > > 
>> > > > > Well, AFAIK there’s no parallelism inside a same .ly file being
>> > > > > processed for different \book outputs. (If there _was_, that would be
>> > > > > great news though!)
>> > > > 
>> > > > Again: file creation and deletion happens while the book is being read
>> > > > in, typesetting happens when the book is being processed.  File handles
>> > > > will tend to stick around until garbage collected.  That is not as much
>> > > > "parallelism" as an absence of order.
>> > > 
>> > > So I am afraid that things are rather weird at my side:
>> > > 
>> > > input/regression/font-name-add-files.ly:244:4: error: GUILE signaled an 
>> > > error for the expression beginning here
>> > >   #
>> > >(rmdir dummyfontdir)
>> > > Directory not empty
>> > > Finding the ideal number of pages...
>> > > Fitting music on 1 page...
>> > > Drawing systems...
>> > > Layout output to `/tmp/lilypond-pXKtKN'...
>> > > Converting to `font-name-add-files-1.pdf'...
>> > > Deleting `/tmp/lilypond-pXKtKN'...
>> > > fatal error: failed files: "input/regression/font-name-add-files.ly"
>> > > dak@lola:/usr/local/tmp/lilypond2$ ls -l dummyfont-C5PUYM-dir/
>> > > total 0
>> > > dak@lola:/usr/local/tmp/lilypond2$ ls -la dummyfont-C5PUYM-dir/
>> > > total 12
>> > > drwxrwxr-x  2 dak dak 4096 Apr 19 19:51 .
>> > > drwxrwxr-x 25 dak dak 4096 Apr 19 19:51 ..
>> > > -rw-r--r--  1 dak dak   36 Apr 19 19:51 .uuid
>> > > dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid 
>> > > 35d52a4b-44f7-41b6-afca-165a4187aa4fdak@lola:/usr/local/tmp/lilypond2$ 
>> > > 
>> > > Does anybody have an idea _what_ and _why_ would leave a .uuid file
>> > > lying around in the temporary file with, well, an uuid kind of number in
>> > > it?  Is that an artifact of my freetype library or something?
>> > 
>> > Seems to be something that fontconfig does.
>> 
>> Just in case:
>> 
>> dak@lola:/usr/local/tmp/lilypond2$ fc-list -V
>> fontconfig version 2.13.1
>
> In case it helps, they're removing the uuid functionality again:
> https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/c4324f54ee16e648ba91f3e9c66af13ab3b1754c
>
> So I guess the fix is to delete the (temporary) directory and all
> contained files? And maybe putting it under /tmp?
>
> Oh, and ignore my comment that I had tested this with Guile 2.2. Looks
> like I didn't (at least not properly).

It may depend on how the literal string enters Guile whether the R/O
detection triggers.

-- 
David Kastrup

Re: Patchy email

Valentin Villenave  writes:

> On 4/19/20, David Kastrup  wrote:
>> mkstemp! does not generate a string.  It overwrites an existing string
>> in-place, and that's bad news for a literal string.
>
> Yes, it overwrite the string,

You can/must not override a literal string.  It's read-only.

> opens a port, then I read the port-filename which should be an _other_
> string object, shouldn’t it?

Why?  At any rate, no problem with appending non-destructively to an
existing string.

> (sigh -- _none_ of this would happen if they hadn’t decided to remove
> tmpnam, or if they had bothered to make tmpnam behave correctly and
> respect TMPDIR, or if they had a mkdtemp!  function.)
>
>> At any rate, you don't write, as the comment states, in a "tmp
>> directory" but rather in the current directory.  If you want a tmp
>> directory, you need to add it to the path.
>
> Yes. I thought mkstemp! was located in the TMPDIR directory (as they
> state in their latest documentation, which is even invoked as the
> rationale for deprecating tmpnam). Turns out it’s merely created in
> the cwd, which isn’t nearly as clean. And I am reluctant to use
> mkstemp! "tmp/foobar-XX" because that would make it
> OS-non-agnostic.

Should be /tmp/foobar-XX anyway unless environment variable TMPDIR
is set in which case you use that.

>> And the .uuid file thing is a real problem with some versions of
>> fontconfig, so I lean to reverting the patch for now.
>
> Unless there is a way to make it safe for all versions and setups.
> (After all, I can test for that .uuid file and delete it if found, or
> rm -rf the subdirectory as I said.)

Preparing a fixed patch is not precluded by reverting it.

> By the way, since you’ve showed us yours, here’s mine:
> $: fc-scan --version
> fontconfig version 2.13.92

Ok, but at least now it's not the upcoming Ubuntu version.

-- 
David Kastrup

Re: Patchy email

Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup:
> David Kastrup <
> d...@gnu.org
> > writes:
> 
> > David Kastrup <
> > d...@gnu.org
> > > writes:
> > 
> > > David Kastrup <
> > > d...@gnu.org
> > > > writes:
> > > 
> > > > Valentin Villenave <
> > > > valen...@villenave.net
> > > > > writes:
> > > > 
> > > > > On 4/19/20, David Kastrup <
> > > > > d...@gnu.org
> > > > > > wrote:
> > > > > > Note that the delete-file instructions are executed while the book 
> > > > > > is
> > > > > > being read in while markup is typeset when the books are being 
> > > > > > processed
> > > > > > at the end of the input file.
> > > > > 
> > > > > Yes, it looked completely bonkers to me as well, until I realized it 
> > > > > worked :-)
> > > > > 
> > > > > > No idea whether the fonts made it into
> > > > > > LilyPond at that point of time, or how happy LilyPond is with them
> > > > > > appearing.
> > > > > 
> > > > > No, because at this point the first \book has already been processed,
> > > > > and even GS should already be invoked. That’s the whole point of
> > > > > putting that stuff inside another \book.
> > > > 
> > > > There is no point in putting the deletion of files "inside another
> > > > \book" since it is not being executed when the book is typeset but when
> > > > the book is read in.
> > > > 
> > > > > > There may well be race conditions here.
> > > > > 
> > > > > Well, AFAIK there’s no parallelism inside a same .ly file being
> > > > > processed for different \book outputs. (If there _was_, that would be
> > > > > great news though!)
> > > > 
> > > > Again: file creation and deletion happens while the book is being read
> > > > in, typesetting happens when the book is being processed.  File handles
> > > > will tend to stick around until garbage collected.  That is not as much
> > > > "parallelism" as an absence of order.
> > > 
> > > So I am afraid that things are rather weird at my side:
> > > 
> > > input/regression/font-name-add-files.ly:244:4: error: GUILE signaled an 
> > > error for the expression beginning here
> > >   #
> > >(rmdir dummyfontdir)
> > > Directory not empty
> > > Finding the ideal number of pages...
> > > Fitting music on 1 page...
> > > Drawing systems...
> > > Layout output to `/tmp/lilypond-pXKtKN'...
> > > Converting to `font-name-add-files-1.pdf'...
> > > Deleting `/tmp/lilypond-pXKtKN'...
> > > fatal error: failed files: "input/regression/font-name-add-files.ly"
> > > dak@lola:/usr/local/tmp/lilypond2$ ls -l dummyfont-C5PUYM-dir/
> > > total 0
> > > dak@lola:/usr/local/tmp/lilypond2$ ls -la dummyfont-C5PUYM-dir/
> > > total 12
> > > drwxrwxr-x  2 dak dak 4096 Apr 19 19:51 .
> > > drwxrwxr-x 25 dak dak 4096 Apr 19 19:51 ..
> > > -rw-r--r--  1 dak dak   36 Apr 19 19:51 .uuid
> > > dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid 
> > > 35d52a4b-44f7-41b6-afca-165a4187aa4fdak@lola:/usr/local/tmp/lilypond2$ 
> > > 
> > > Does anybody have an idea _what_ and _why_ would leave a .uuid file
> > > lying around in the temporary file with, well, an uuid kind of number in
> > > it?  Is that an artifact of my freetype library or something?
> > 
> > Seems to be something that fontconfig does.
> 
> Just in case:
> 
> dak@lola:/usr/local/tmp/lilypond2$ fc-list -V
> fontconfig version 2.13.1

In case it helps, they're removing the uuid functionality again:
https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/c4324f54ee16e648ba91f3e9c66af13ab3b1754c

So I guess the fix is to delete the (temporary) directory and all
contained files? And maybe putting it under /tmp?

Oh, and ignore my comment that I had tested this with Guile 2.2. Looks
like I didn't (at least not properly).


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

Re: Patchy email

2020-04-19 Thread Werner LEMBERG



>>> Does anybody have an idea _what_ and _why_ would leave a .uuid
>>> file lying around in the temporary file with, well, an uuid kind
>>> of number in it?  Is that an artifact of my freetype library or
>>> something?

Definitely not FreeType, but...

>> Seems to be something that fontconfig does.

... now that you mention it, I remember an issue with that on the
fontconfig e-mail list.

> dak@lola:/usr/local/tmp/lilypond2$ fc-list -V
> fontconfig version 2.13.1

We probably have to work around this fontconfig bug for user
convenience...


Werner

Re: Patchy email

On 4/19/20, David Kastrup  wrote:
> mkstemp! does not generate a string.  It overwrites an existing string
> in-place, and that's bad news for a literal string.

Yes, it overwrite the string, opens a port, then I read the
port-filename which should be an _other_ string object, shouldn’t it?
(sigh -- _none_ of this would happen if they hadn’t decided to remove
tmpnam, or if they had bothered to make tmpnam behave correctly and
respect TMPDIR, or if they had a mkdtemp! function.)

> At any rate, you don't write, as the comment states, in a "tmp
> directory" but rather in the current directory.  If you want a tmp
> directory, you need to add it to the path.

Yes. I thought mkstemp! was located in the TMPDIR directory (as they
state in their latest documentation, which is even invoked as the
rationale for deprecating tmpnam). Turns out it’s merely created in
the cwd, which isn’t nearly as clean. And I am reluctant to use
mkstemp! "tmp/foobar-XX" because that would make it
OS-non-agnostic.

> And the .uuid file thing is a real problem with some versions of
> fontconfig, so I lean to reverting the patch for now.

Unless there is a way to make it safe for all versions and setups.
(After all, I can test for that .uuid file and delete it if found, or
rm -rf the subdirectory as I said.)

By the way, since you’ve showed us yours, here’s mine:
$: fc-scan --version
fontconfig version 2.13.92

V.

Re: Patchy email

On 4/19/20, David Kastrup  wrote:
> So I am afraid that things are rather weird at my side:
> -rw-r--r--  1 dak dak   36 Apr 19 19:51 .uuid
> dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid
> 35d52a4b-44f7-41b6-afca-165a4187aa4f

WTF. Could it be some trace left due to your filesystem?

Wait a minute, I found this Debian bug report about fontconfig:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897040#21

V.

Re: Patchy email

Valentin Villenave  writes:

> On 4/19/20, David Kastrup  wrote:
>> You need (mkstemp! (string-copy "...
>> because mkstemp! overrides the string.
>
> Why, yes. What I want to copy is precisely the mkstemp-generated
> string. What did I miss?

mkstemp! does not generate a string.  It overwrites an existing string
in-place, and that's bad news for a literal string.

At any rate, you don't write, as the comment states, in a "tmp
directory" but rather in the current directory.  If you want a tmp
directory, you need to add it to the path.

And the .uuid file thing is a real problem with some versions of
fontconfig, so I lean to reverting the patch for now.

-- 
David Kastrup

Re: Patchy email

On 4/19/20, David Kastrup  wrote:
> You need (mkstemp! (string-copy "...
> because mkstemp! overrides the string.

Why, yes. What I want to copy is precisely the mkstemp-generated
string. What did I miss?

V.

Re: Patchy email

David Kastrup  writes:

> David Kastrup  writes:
>
>> David Kastrup  writes:
>>
>>> Valentin Villenave  writes:
>>>
 On 4/19/20, David Kastrup  wrote:
> Note that the delete-file instructions are executed while the book is
> being read in while markup is typeset when the books are being processed
> at the end of the input file.

 Yes, it looked completely bonkers to me as well, until I realized it 
 worked :-)

> No idea whether the fonts made it into
> LilyPond at that point of time, or how happy LilyPond is with them
> appearing.

 No, because at this point the first \book has already been processed,
 and even GS should already be invoked. That’s the whole point of
 putting that stuff inside another \book.
>>>
>>> There is no point in putting the deletion of files "inside another
>>> \book" since it is not being executed when the book is typeset but when
>>> the book is read in.
>>>
> There may well be race conditions here.

 Well, AFAIK there’s no parallelism inside a same .ly file being
 processed for different \book outputs. (If there _was_, that would be
 great news though!)
>>>
>>> Again: file creation and deletion happens while the book is being read
>>> in, typesetting happens when the book is being processed.  File handles
>>> will tend to stick around until garbage collected.  That is not as much
>>> "parallelism" as an absence of order.
>>
>> So I am afraid that things are rather weird at my side:
>>
>> input/regression/font-name-add-files.ly:244:4: error: GUILE signaled an 
>> error for the expression beginning here
>>   #
>>(rmdir dummyfontdir)
>> Directory not empty
>> Finding the ideal number of pages...
>> Fitting music on 1 page...
>> Drawing systems...
>> Layout output to `/tmp/lilypond-pXKtKN'...
>> Converting to `font-name-add-files-1.pdf'...
>> Deleting `/tmp/lilypond-pXKtKN'...
>> fatal error: failed files: "input/regression/font-name-add-files.ly"
>> dak@lola:/usr/local/tmp/lilypond2$ ls -l dummyfont-C5PUYM-dir/
>> total 0
>> dak@lola:/usr/local/tmp/lilypond2$ ls -la dummyfont-C5PUYM-dir/
>> total 12
>> drwxrwxr-x  2 dak dak 4096 Apr 19 19:51 .
>> drwxrwxr-x 25 dak dak 4096 Apr 19 19:51 ..
>> -rw-r--r--  1 dak dak   36 Apr 19 19:51 .uuid
>> dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid 
>> 35d52a4b-44f7-41b6-afca-165a4187aa4fdak@lola:/usr/local/tmp/lilypond2$ 
>>
>> Does anybody have an idea _what_ and _why_ would leave a .uuid file
>> lying around in the temporary file with, well, an uuid kind of number in
>> it?  Is that an artifact of my freetype library or something?
>
> Seems to be something that fontconfig does.

Just in case:

dak@lola:/usr/local/tmp/lilypond2$ fc-list -V
fontconfig version 2.13.1

-- 
David Kastrup

Re: Patchy email

David Kastrup  writes:

> David Kastrup  writes:
>
>> Valentin Villenave  writes:
>>
>>> On 4/19/20, David Kastrup  wrote:
 Note that the delete-file instructions are executed while the book is
 being read in while markup is typeset when the books are being processed
 at the end of the input file.
>>>
>>> Yes, it looked completely bonkers to me as well, until I realized it worked 
>>> :-)
>>>
 No idea whether the fonts made it into
 LilyPond at that point of time, or how happy LilyPond is with them
 appearing.
>>>
>>> No, because at this point the first \book has already been processed,
>>> and even GS should already be invoked. That’s the whole point of
>>> putting that stuff inside another \book.
>>
>> There is no point in putting the deletion of files "inside another
>> \book" since it is not being executed when the book is typeset but when
>> the book is read in.
>>
 There may well be race conditions here.
>>>
>>> Well, AFAIK there’s no parallelism inside a same .ly file being
>>> processed for different \book outputs. (If there _was_, that would be
>>> great news though!)
>>
>> Again: file creation and deletion happens while the book is being read
>> in, typesetting happens when the book is being processed.  File handles
>> will tend to stick around until garbage collected.  That is not as much
>> "parallelism" as an absence of order.
>
> So I am afraid that things are rather weird at my side:
>
> input/regression/font-name-add-files.ly:244:4: error: GUILE signaled an error 
> for the expression beginning here
>   #
>(rmdir dummyfontdir)
> Directory not empty
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to `/tmp/lilypond-pXKtKN'...
> Converting to `font-name-add-files-1.pdf'...
> Deleting `/tmp/lilypond-pXKtKN'...
> fatal error: failed files: "input/regression/font-name-add-files.ly"
> dak@lola:/usr/local/tmp/lilypond2$ ls -l dummyfont-C5PUYM-dir/
> total 0
> dak@lola:/usr/local/tmp/lilypond2$ ls -la dummyfont-C5PUYM-dir/
> total 12
> drwxrwxr-x  2 dak dak 4096 Apr 19 19:51 .
> drwxrwxr-x 25 dak dak 4096 Apr 19 19:51 ..
> -rw-r--r--  1 dak dak   36 Apr 19 19:51 .uuid
> dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid 
> 35d52a4b-44f7-41b6-afca-165a4187aa4fdak@lola:/usr/local/tmp/lilypond2$ 
>
> Does anybody have an idea _what_ and _why_ would leave a .uuid file
> lying around in the temporary file with, well, an uuid kind of number in
> it?  Is that an artifact of my freetype library or something?

Seems to be something that fontconfig does.

-- 
David Kastrup

Re: Patchy email

David Kastrup  writes:

> Valentin Villenave  writes:
>
>> On 4/19/20, David Kastrup  wrote:
>>> Note that the delete-file instructions are executed while the book is
>>> being read in while markup is typeset when the books are being processed
>>> at the end of the input file.
>>
>> Yes, it looked completely bonkers to me as well, until I realized it worked 
>> :-)
>>
>>> No idea whether the fonts made it into
>>> LilyPond at that point of time, or how happy LilyPond is with them
>>> appearing.
>>
>> No, because at this point the first \book has already been processed,
>> and even GS should already be invoked. That’s the whole point of
>> putting that stuff inside another \book.
>
> There is no point in putting the deletion of files "inside another
> \book" since it is not being executed when the book is typeset but when
> the book is read in.
>
>>> There may well be race conditions here.
>>
>> Well, AFAIK there’s no parallelism inside a same .ly file being
>> processed for different \book outputs. (If there _was_, that would be
>> great news though!)
>
> Again: file creation and deletion happens while the book is being read
> in, typesetting happens when the book is being processed.  File handles
> will tend to stick around until garbage collected.  That is not as much
> "parallelism" as an absence of order.

So I am afraid that things are rather weird at my side:

input/regression/font-name-add-files.ly:244:4: error: GUILE signaled an error 
for the expression beginning here
  #
   (rmdir dummyfontdir)
Directory not empty
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-pXKtKN'...
Converting to `font-name-add-files-1.pdf'...
Deleting `/tmp/lilypond-pXKtKN'...
fatal error: failed files: "input/regression/font-name-add-files.ly"
dak@lola:/usr/local/tmp/lilypond2$ ls -l dummyfont-C5PUYM-dir/
total 0
dak@lola:/usr/local/tmp/lilypond2$ ls -la dummyfont-C5PUYM-dir/
total 12
drwxrwxr-x  2 dak dak 4096 Apr 19 19:51 .
drwxrwxr-x 25 dak dak 4096 Apr 19 19:51 ..
-rw-r--r--  1 dak dak   36 Apr 19 19:51 .uuid
dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid 
35d52a4b-44f7-41b6-afca-165a4187aa4fdak@lola:/usr/local/tmp/lilypond2$ 

Does anybody have an idea _what_ and _why_ would leave a .uuid file
lying around in the temporary file with, well, an uuid kind of number in
it?  Is that an artifact of my freetype library or something?

-- 
David Kastrup

Re: Patchy email

Valentin Villenave  writes:

> On 4/19/20, David Kastrup  wrote:
>> ERROR: In procedure mkstemp!:
>> string is read-only: "kaka-XX"
>
> Could  the following help?
>
> diff --git a/input/regression/font-name-add-files.ly
> b/input/regression/font-name-add-files.ly
> index 33f73f0c68..264e2b6532 100644
> --- a/input/regression/font-name-add-files.ly
> +++ b/input/regression/font-name-add-files.ly
> @@ -22,7 +22,7 @@ rather than a letter glyph."
>  %% but since there’s no mkdtemp in Guile, we need to fiddle with
>  %% filename strings anyway:
>
> -dummyname = #(port-filename (mkstemp! "dummyfont-XX"))
> +dummyname = #(string-copy (port-filename (mkstemp! "dummyfont-XX")))
>
>  dummyfontfile = #(string-append dummyname "-font.otf")
>  dummyfontdir = #(string-append dummyname "-dir")

No, that's the wrong way round.  You need (mkstemp! (string-copy "...
because mkstemp! overrides the string.

-- 
David Kastrup

Re: Patchy email

Valentin Villenave  writes:

> On 4/19/20, David Kastrup  wrote:
>> Note that the delete-file instructions are executed while the book is
>> being read in while markup is typeset when the books are being processed
>> at the end of the input file.
>
> Yes, it looked completely bonkers to me as well, until I realized it worked 
> :-)
>
>> No idea whether the fonts made it into
>> LilyPond at that point of time, or how happy LilyPond is with them
>> appearing.
>
> No, because at this point the first \book has already been processed,
> and even GS should already be invoked. That’s the whole point of
> putting that stuff inside another \book.

There is no point in putting the deletion of files "inside another
\book" since it is not being executed when the book is typeset but when
the book is read in.

>> There may well be race conditions here.
>
> Well, AFAIK there’s no parallelism inside a same .ly file being
> processed for different \book outputs. (If there _was_, that would be
> great news though!)

Again: file creation and deletion happens while the book is being read
in, typesetting happens when the book is being processed.  File handles
will tend to stick around until garbage collected.  That is not as much
"parallelism" as an absence of order.

-- 
David Kastrup

Re: Patchy email

On 4/19/20, David Kastrup  wrote:
> Note that the delete-file instructions are executed while the book is
> being read in while markup is typeset when the books are being processed
> at the end of the input file.

Yes, it looked completely bonkers to me as well, until I realized it worked :-)

> No idea whether the fonts made it into
> LilyPond at that point of time, or how happy LilyPond is with them
> appearing.

No, because at this point the first \book has already been processed,
and even GS should already be invoked. That’s the whole point of
putting that stuff inside another \book.

> There may well be race conditions here.

Well, AFAIK there’s no parallelism inside a same .ly file being
processed for different \book outputs. (If there _was_, that would be
great news though!)

V.

Re: Patchy email

On 4/19/20, David Kastrup  wrote:
> ERROR: In procedure mkstemp!:
> string is read-only: "kaka-XX"

Could  the following help?

diff --git a/input/regression/font-name-add-files.ly
b/input/regression/font-name-add-files.ly
index 33f73f0c68..264e2b6532 100644
--- a/input/regression/font-name-add-files.ly
+++ b/input/regression/font-name-add-files.ly
@@ -22,7 +22,7 @@ rather than a letter glyph."
 %% but since there’s no mkdtemp in Guile, we need to fiddle with
 %% filename strings anyway:

-dummyname = #(port-filename (mkstemp! "dummyfont-XX"))
+dummyname = #(string-copy (port-filename (mkstemp! "dummyfont-XX")))

 dummyfontfile = #(string-append dummyname "-font.otf")
 dummyfontdir = #(string-append dummyname "-dir")


V.

Re: Patchy email

Jonas Hahnfeld  writes:

> Am Sonntag, den 19.04.2020, 19:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>> 
>> > Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> > > pat...@gnu.org
>> > > 
>> > >  writes:
>> > > 
>> > > > 16:36:18 (UTC) Begin LilyPond compile, previous commit at  
>> > > > 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > > > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
>> > > >12bf65758f..0cfef7069e  master -> origin/master
>> > > >12bf65758f..0cfef7069e  staging-> origin/staging
>> > > > 16:36:27 Merged staging, now at:   
>> > > > 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > > > 16:36:28   Success:./autogen.sh --noconfigure
>> > > > 16:36:40   Success:
>> > > > /tmp/lilypond-autobuild/configure --enable-checking
>> > > > 16:36:43   Success:nice make clean
>> > > > 16:40:45   Success:nice make -j9 CPU_COUNT=9
>> > > > 16:42:04 *** FAILED BUILD ***
>> > > >nice make test -j9 CPU_COUNT=9
>> > > >Previous good commit:   12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > > >Current broken commit:  0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > > > 16:42:04 *** 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
>> > > > 16:42:04 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
>> > > 
>> > > That's again font-name-add-files.ly .
>> > 
>> > Could you maybe share the exact error from make? I've been running this
>> > patch during the countdown and it also passes James' testing...
>> 
>> I just get the filename so far.  However, there is the following:
>> 
>> dak@lola:/usr/local/tmp/lilypond$ guile
>> GNU Guile 2.2.7
>> Copyright (C) 1995-2019 Free Software Foundation, Inc.
>> 
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>> 
>> Enter `,help' for help.
>> scheme@(guile-user)> (define bla (mkstemp! "kaka-XX"))
>> ERROR: In procedure mkstemp!:
>> string is read-only: "kaka-XX"
>> 
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [1]> 
>> 
>> I use Guile-1.8 in my Patchy (I hope) which should not detect this bug
>> but it still seems worth fixing as it breaks with Guile-2 at the latest.
>> 
>> Also the file that is being created is not being created in some
>> temporary directory but in the _current_ directory.  Not sure whether
>> that has something to do with it.
>
> It's passing right now with "my" Guile 1.8 and I gave it a try last
> week with Guile 2.2, without seeing an issue. Weird

There is also

\book {

#(let* ((port (open-output-file dummyfontfile)))
  (base64-decode port dummyfont)
  (close port))

#(ly:font-config-add-font dummyfontfile)

\markup \fontsize #20 \override #'(font-name . "DummyGPL") "A"

#(mkdir dummyfontdir)

#(let* ((port (open-output-file dummyfontfileInSubdir)))
   (base64-decode port dummyfontAlt)
   (close port))

#(ly:font-config-add-directory dummyfontdir)

\markup \fontsize #20 \override #'(font-name . "DummyGFDL") "A"
}

%% This will not appear in collated files:

\book {
  #(delete-file dummyname)
  #(delete-file dummyfontfile)
  #(delete-file dummyfontfileInSubdir)
  #(rmdir dummyfontdir)
  \markup { These files and directories should have been removed:}

Note that the delete-file instructions are executed while the book is
being read in while markup is typeset when the books are being processed
at the end of the input file.  No idea whether the fonts made it into
LilyPond at that point of time, or how happy LilyPond is with them
appearing.  It might be appending to the font directory after it already
has been deleted?

There may well be race conditions here.

-- 
David Kastrup

Re: Patchy email

Am Sonntag, den 19.04.2020, 19:07 +0200 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
> > > pat...@gnu.org
> > > 
> > >  writes:
> > > 
> > > > 16:36:18 (UTC) Begin LilyPond compile, previous commit at   
> > > > 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > > > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
> > > >12bf65758f..0cfef7069e  master -> origin/master
> > > >12bf65758f..0cfef7069e  staging-> origin/staging
> > > > 16:36:27 Merged staging, now at:
> > > > 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > > > 16:36:28Success:./autogen.sh --noconfigure
> > > > 16:36:40Success:
> > > > /tmp/lilypond-autobuild/configure --enable-checking
> > > > 16:36:43Success:nice make clean
> > > > 16:40:45Success:nice make -j9 CPU_COUNT=9
> > > > 16:42:04 *** FAILED BUILD ***
> > > > nice make test -j9 CPU_COUNT=9
> > > > Previous good commit:   12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > > > Current broken commit:  0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > > > 16:42:04 *** 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
> > > > 16:42:04 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
> > > 
> > > That's again font-name-add-files.ly .
> > 
> > Could you maybe share the exact error from make? I've been running this
> > patch during the countdown and it also passes James' testing...
> 
> I just get the filename so far.  However, there is the following:
> 
> dak@lola:/usr/local/tmp/lilypond$ guile
> GNU Guile 2.2.7
> Copyright (C) 1995-2019 Free Software Foundation, Inc.
> 
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
> 
> Enter `,help' for help.
> scheme@(guile-user)> (define bla (mkstemp! "kaka-XX"))
> ERROR: In procedure mkstemp!:
> string is read-only: "kaka-XX"
> 
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> 
> 
> I use Guile-1.8 in my Patchy (I hope) which should not detect this bug
> but it still seems worth fixing as it breaks with Guile-2 at the latest.
> 
> Also the file that is being created is not being created in some
> temporary directory but in the _current_ directory.  Not sure whether
> that has something to do with it.

It's passing right now with "my" Guile 1.8 and I gave it a try last
week with Guile 2.2, without seeing an issue. Weird


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

Re: Patchy email

Jonas Hahnfeld  writes:

> Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> pat...@gnu.org
>>  writes:
>> 
>> > 16:36:18 (UTC) Begin LilyPond compile, previous commit at  
>> > 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
>> >12bf65758f..0cfef7069e  master -> origin/master
>> >12bf65758f..0cfef7069e  staging-> origin/staging
>> > 16:36:27 Merged staging, now at:   0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > 16:36:28   Success:./autogen.sh --noconfigure
>> > 16:36:40   Success:/tmp/lilypond-autobuild/configure 
>> > --enable-checking
>> > 16:36:43   Success:nice make clean
>> > 16:40:45   Success:nice make -j9 CPU_COUNT=9
>> > 16:42:04 *** FAILED BUILD ***
>> >nice make test -j9 CPU_COUNT=9
>> >Previous good commit:   12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> >Current broken commit:  0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > 16:42:04 *** 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
>> > 16:42:04 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
>> 
>> That's again font-name-add-files.ly .
>
> Could you maybe share the exact error from make? I've been running this
> patch during the countdown and it also passes James' testing...

I just get the filename so far.  However, there is the following:

dak@lola:/usr/local/tmp/lilypond$ guile
GNU Guile 2.2.7
Copyright (C) 1995-2019 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (define bla (mkstemp! "kaka-XX"))
ERROR: In procedure mkstemp!:
string is read-only: "kaka-XX"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 

I use Guile-1.8 in my Patchy (I hope) which should not detect this bug
but it still seems worth fixing as it breaks with Guile-2 at the latest.

Also the file that is being created is not being created in some
temporary directory but in the _current_ directory.  Not sure whether
that has something to do with it.

-- 
David Kastrup

Re: Patchy email

Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
> pat...@gnu.org
>  writes:
> 
> > 16:36:18 (UTC) Begin LilyPond compile, previous commit at   
> > 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
> >12bf65758f..0cfef7069e  master -> origin/master
> >12bf65758f..0cfef7069e  staging-> origin/staging
> > 16:36:27 Merged staging, now at:0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > 16:36:28Success:./autogen.sh --noconfigure
> > 16:36:40Success:/tmp/lilypond-autobuild/configure 
> > --enable-checking
> > 16:36:43Success:nice make clean
> > 16:40:45Success:nice make -j9 CPU_COUNT=9
> > 16:42:04 *** FAILED BUILD ***
> > nice make test -j9 CPU_COUNT=9
> > Previous good commit:   12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > Current broken commit:  0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > 16:42:04 *** 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
> > 16:42:04 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
> 
> That's again font-name-add-files.ly .

Could you maybe share the exact error from make? I've been running this
patch during the countdown and it also passes James' testing...


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

Re: Patchy email

pat...@gnu.org writes:

> 16:36:18 (UTC) Begin LilyPond compile, previous commit at 
> 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
>12bf65758f..0cfef7069e  master -> origin/master
>12bf65758f..0cfef7069e  staging-> origin/staging
> 16:36:27 Merged staging, now at:  0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> 16:36:28  Success:./autogen.sh --noconfigure
> 16:36:40  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 16:36:43  Success:nice make clean
> 16:40:45  Success:nice make -j9 CPU_COUNT=9
> 16:42:04 *** FAILED BUILD ***
>   nice make test -j9 CPU_COUNT=9
>   Previous good commit:   12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>   Current broken commit:  0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> 16:42:04 *** 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
> 16:42:04 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

That's again font-name-add-files.ly .

-- 
David Kastrup

Patchy email

2020-04-19 Thread patchy

16:36:18 (UTC) Begin LilyPond compile, previous commit at   
12bf65758f33510e6b8e6e4d4a91bb1ebb459248
16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
   12bf65758f..0cfef7069e  master -> origin/master
   12bf65758f..0cfef7069e  staging-> origin/staging
16:36:27 Merged staging, now at:0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
16:36:28Success:./autogen.sh --noconfigure
16:36:40Success:/tmp/lilypond-autobuild/configure 
--enable-checking
16:36:43Success:nice make clean
16:40:45Success:nice make -j9 CPU_COUNT=9
16:42:04 *** FAILED BUILD ***
nice make test -j9 CPU_COUNT=9
Previous good commit:   12bf65758f33510e6b8e6e4d4a91bb1ebb459248
Current broken commit:  0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
16:42:04 *** 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
16:42:04 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

Patchy email

2020-04-09 Thread patchy

14:41:10 (UTC) Begin LilyPond compile, previous commit at   
1dd353f70131eabd43a1b6455d6d05b58fb9db79
14:41:19 Merged staging, now at:1dd353f70131eabd43a1b6455d6d05b58fb9db79
14:41:19Success:./autogen.sh --noconfigure
14:41:33Success:/tmp/lilypond-autobuild/configure 
--enable-checking
14:41:36Success:nice make clean
14:45:54Success:nice make -j9 CPU_COUNT=9
14:47:18 *** FAILED BUILD ***
nice make test -j9 CPU_COUNT=9
Previous good commit:   65932b8fde202a95b7fbf9f400c01c75fa53519f
Current broken commit:  1dd353f70131eabd43a1b6455d6d05b58fb9db79
14:47:18 *** 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:18 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

Re: Patchy email

2020-03-25 Thread Valentin Villenave

On 3/25/20, Werner LEMBERG  wrote:
> Oops, I gave wrong advice, sorry.

You’re not the one to blame; I was the one who jumped the gun.

> Please do
>   s/@example/@samp/
> and re-commit.

Done. Aand this is why we have a patch reviewing process. Lesson
learned. (Again.)

V.

Re: Patchy email

2020-03-24 Thread Werner LEMBERG

> makeinfo.notation.log states:
> 
>   out/notation/rhythms.texi:1961: misplaced {
>   out/notation/rhythms.texi:1961: misplaced }
> 
> The respective line appears to be:
> 
>   the note name uppercase @example{R}.  Their duration is entered
> 
> @example is not an in-text command but rather an environment.
> Backing out the respective commit from staging.

Oops, I gave wrong advice, sorry.  Please do

  s/@example/@samp/

and re-commit.


Werner

Re: Patchy email

2020-03-24 Thread David Kastrup

pat...@gnu.org writes:

> 22:26:26 (UTC) Begin LilyPond compile, previous commit at 
> 83045b846acb4aaadf54373941a915c4c45fb522
> 22:26:34 Merged staging, now at:  83045b846acb4aaadf54373941a915c4c45fb522
> 22:26:35  Success:./autogen.sh --noconfigure
> 22:26:47  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 22:26:51  Success:nice make clean
> 22:30:49 *** FAILED BUILD ***
>   nice make -j9 CPU_COUNT=9
>   Previous good commit:   786c3669ff08804465a89013d349fc745fd783c9
>   Current broken commit:  83045b846acb4aaadf54373941a915c4c45fb522
> 22:30:49 *** FAILED STEP ***
>   merge from staging
>   Failed runner: nice make -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
> 22:30:49 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 316, 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 -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
>
>

makeinfo.notation.log states:

out/notation/rhythms.texi:1961: misplaced {
out/notation/rhythms.texi:1961: misplaced }

The respective line appears to be:

the note name uppercase @example{R}.  Their duration is entered

@example is not an in-text command but rather an environment.

Backing out the respective commit from staging.

All the best.

-- 
David Kastrup

Patchy email

2020-03-24 Thread patchy

22:26:26 (UTC) Begin LilyPond compile, previous commit at   
83045b846acb4aaadf54373941a915c4c45fb522
22:26:34 Merged staging, now at:83045b846acb4aaadf54373941a915c4c45fb522
22:26:35Success:./autogen.sh --noconfigure
22:26:47Success:/tmp/lilypond-autobuild/configure 
--enable-checking
22:26:51Success:nice make clean
22:30:49 *** FAILED BUILD ***
nice make -j9 CPU_COUNT=9
Previous good commit:   786c3669ff08804465a89013d349fc745fd783c9
Current broken commit:  83045b846acb4aaadf54373941a915c4c45fb522
22:30:49 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
22:30:49 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 
316, 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 -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt

Re: Patchy email (guile 1.8 instructions)

pkx1...@posteo.net writes:

> David,
>
> On 07/03/2020 00:59, David Kastrup wrote:
>> David Kastrup  writes:
>>
>>> pat...@gnu.org writes:
>>>
 23:42:58 (UTC) Begin LilyPond compile, previous commit at  
 bf6f650dbc16cb33181501eee2aca082a5a5e3ef
 23:43:05 Merged staging, now at:   bf6f650dbc16cb33181501eee2aca082a5a5e3ef
 23:43:06   Success:./autogen.sh --noconfigure
 23:43:18   Success:/tmp/lilypond-autobuild/configure 
 --enable-checking
 23:43:21   Success:nice make clean
 23:46:54   Success:nice make -j9 CPU_COUNT=9
 23:51:15   Success:nice make test -j9 CPU_COUNT=9
 23:54:59 *** FAILED BUILD ***
nice make doc -j9 CPU_COUNT=9
Previous good commit:   825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
Current broken commit:  bf6f650dbc16cb33181501eee2aca082a5a5e3ef
 23:54:59 *** FAILED STEP ***
merge from staging
Failed runner: nice make doc -j9 CPU_COUNT=9
 See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
 23:54:59 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 333, 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 doc -j9 CPU_COUNT=9
 See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>>> So I am suddenly seeing comparatively frequent segfaults in my patchy
>>> runs while building the docs.  This is the second time in as many days
>>> (or not more than 3 days I guess).
>>>
>>> My prime candidates are basically Han-Wen's job control for
>>> lilypond-book (could lead to out-of-memory conditions on my system and I
>>> don't think we handle exceptions other than aborting currently) and
>>> Torsten Hämmerle's French beaming stuff.  I read through that patch a
>>> few times but did not see any red flags.
>>>
>>> To track this down, I'll now enable core dumps and hope that eventually
>>> I'll be able to get a relevant one.  I'll stick at current settings for
>>> now.
>> Ok, I am seriously annoyed right now.  I have in my Patchy config (and
>> use in my normal compilations)
>>
>> [configure_environment]
>> GUILE=/usr/bin/guile
>> GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config
>>
>> but GUILE_CONFIG is now being ignored.  What is the current invocation I
>> am supposed to use to get my own version of GUILE?  Where is this
>> documented?
>>
>> ./configure --help
>>
>> does not say _anything_ here.
>>
>> This is pretty important for people like Debian system integrators that
>> include a version of Guile-1.8.  That is now getting ignored by default,
>> and there is no documented way of getting it.
>>
> I built a couple of new new Ubuntu 18.04 VMs at work last week (I like
> to re-aquaint myself with the steps to build a working LP dev machine 
> now and then).
>
> For Guile I always use the instructions from Federico that he sent to
> the mailing lists
>
> https://lists.gnu.org/archive/html/lilypond-devel/2017-10/msg00130.html
>
> --snip--
>
> git clone https://git.savannah.gnu.org/git/guile.git
> cd guile
> git checkout branch_release-1-8
> ./autogen.sh
> ./configure --disable-error-on-warning --prefix=/usr/local
> make
> sudo make install
> sudo ldconfig
>
> echo "GUILE_CONFIG=/usr/local/bin/guile-config" >> ~/.bashrc
>
> --snip--
>
> P.S. I am running a patchy staging myself right now.

GUILE_CONFIG is now being ignored.  It's possible that pkgconfig picks
up /usr/local/lib/pkgconfig/guile-1.8.pc on your system now and that
your system works in that manner.

But with a privately installed Guile-1.8 like mine (namely a more
specific prefix than /usr/local ), this recipe will no longer work.

-- 
David Kastrup

Re: Patchy email (guile 1.8 instructions)

2020-03-06 Thread pkx166h


David,

On 07/03/2020 00:59, David Kastrup wrote:

David Kastrup  writes:


pat...@gnu.org writes:


23:42:58 (UTC) Begin LilyPond compile, previous commit at   
bf6f650dbc16cb33181501eee2aca082a5a5e3ef
23:43:05 Merged staging, now at:bf6f650dbc16cb33181501eee2aca082a5a5e3ef
23:43:06Success:./autogen.sh --noconfigure
23:43:18Success:/tmp/lilypond-autobuild/configure 
--enable-checking
23:43:21Success:nice make clean
23:46:54Success:nice make -j9 CPU_COUNT=9
23:51:15Success:nice make test -j9 CPU_COUNT=9
23:54:59 *** FAILED BUILD ***
nice make doc -j9 CPU_COUNT=9
Previous good commit:   825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
Current broken commit:  bf6f650dbc16cb33181501eee2aca082a5a5e3ef
23:54:59 *** FAILED STEP ***
merge from staging
Failed runner: nice make doc -j9 CPU_COUNT=9
See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
23:54:59 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 
333, 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 doc -j9 CPU_COUNT=9
See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt

So I am suddenly seeing comparatively frequent segfaults in my patchy
runs while building the docs.  This is the second time in as many days
(or not more than 3 days I guess).

My prime candidates are basically Han-Wen's job control for
lilypond-book (could lead to out-of-memory conditions on my system and I
don't think we handle exceptions other than aborting currently) and
Torsten Hämmerle's French beaming stuff.  I read through that patch a
few times but did not see any red flags.

To track this down, I'll now enable core dumps and hope that eventually
I'll be able to get a relevant one.  I'll stick at current settings for
now.

Ok, I am seriously annoyed right now.  I have in my Patchy config (and
use in my normal compilations)

[configure_environment]
GUILE=/usr/bin/guile
GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config

but GUILE_CONFIG is now being ignored.  What is the current invocation I
am supposed to use to get my own version of GUILE?  Where is this
documented?

./configure --help

does not say _anything_ here.

This is pretty important for people like Debian system integrators that
include a version of Guile-1.8.  That is now getting ignored by default,
and there is no documented way of getting it.

I built a couple of new new Ubuntu 18.04 VMs at work last week (I like 
to re-aquaint myself with the steps to build a working LP dev machine 
now and then).


For Guile I always use the instructions from Federico that he sent to 
the mailing lists


https://lists.gnu.org/archive/html/lilypond-devel/2017-10/msg00130.html

--snip--

git clone https://git.savannah.gnu.org/git/guile.git
cd guile
git checkout branch_release-1-8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
sudo make install
sudo ldconfig

echo "GUILE_CONFIG=/usr/local/bin/guile-config" >> ~/.bashrc

--snip--

P.S. I am running a patchy staging myself right now.


James

Re: Patchy email

David Kastrup  writes:

> pat...@gnu.org writes:
>
>> 23:42:58 (UTC) Begin LilyPond compile, previous commit at
>> bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:05 Merged staging, now at: bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:06 Success:./autogen.sh --noconfigure
>> 23:43:18 Success:/tmp/lilypond-autobuild/configure 
>> --enable-checking
>> 23:43:21 Success:nice make clean
>> 23:46:54 Success:nice make -j9 CPU_COUNT=9
>> 23:51:15 Success:nice make test -j9 CPU_COUNT=9
>> 23:54:59 *** FAILED BUILD ***
>>  nice make doc -j9 CPU_COUNT=9
>>  Previous good commit:   825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>>  Current broken commit:  bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:54:59 *** FAILED STEP ***
>>  merge from staging
>>  Failed runner: nice make doc -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>> 23:54:59 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 333, 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 doc -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>
> So I am suddenly seeing comparatively frequent segfaults in my patchy
> runs while building the docs.  This is the second time in as many days
> (or not more than 3 days I guess).
>
> My prime candidates are basically Han-Wen's job control for
> lilypond-book (could lead to out-of-memory conditions on my system and I
> don't think we handle exceptions other than aborting currently) and
> Torsten Hämmerle's French beaming stuff.  I read through that patch a
> few times but did not see any red flags.
>
> To track this down, I'll now enable core dumps and hope that eventually
> I'll be able to get a relevant one.  I'll stick at current settings for
> now.

Ok, I am seriously annoyed right now.  I have in my Patchy config (and
use in my normal compilations)

[configure_environment]
GUILE=/usr/bin/guile
GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config

but GUILE_CONFIG is now being ignored.  What is the current invocation I
am supposed to use to get my own version of GUILE?  Where is this
documented?

./configure --help

does not say _anything_ here.

This is pretty important for people like Debian system integrators that
include a version of Guile-1.8.  That is now getting ignored by default,
and there is no documented way of getting it.

-- 
David Kastrup

Re: Patchy email

David Kastrup  writes:

> pat...@gnu.org writes:
>
>> 23:42:58 (UTC) Begin LilyPond compile, previous commit at
>> bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:05 Merged staging, now at: bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:06 Success:./autogen.sh --noconfigure
>> 23:43:18 Success:/tmp/lilypond-autobuild/configure 
>> --enable-checking
>> 23:43:21 Success:nice make clean
>> 23:46:54 Success:nice make -j9 CPU_COUNT=9
>> 23:51:15 Success:nice make test -j9 CPU_COUNT=9
>> 23:54:59 *** FAILED BUILD ***
>>  nice make doc -j9 CPU_COUNT=9
>>  Previous good commit:   825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>>  Current broken commit:  bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:54:59 *** FAILED STEP ***
>>  merge from staging
>>  Failed runner: nice make doc -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>> 23:54:59 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 333, 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 doc -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>
> So I am suddenly seeing comparatively frequent segfaults in my patchy
> runs while building the docs.  This is the second time in as many days
> (or not more than 3 days I guess).
>
> My prime candidates are basically Han-Wen's job control for
> lilypond-book (could lead to out-of-memory conditions on my system and I
> don't think we handle exceptions other than aborting currently) and
> Torsten Hämmerle's French beaming stuff.  I read through that patch a
> few times but did not see any red flags.
>
> To track this down, I'll now enable core dumps and hope that eventually
> I'll be able to get a relevant one.  I'll stick at current settings for
> now.

Bah.  ldd out/bin/lilypond shows that I have been compiling with
libguile-2.2.

libguile-2.2.so.1 => /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
(0x7f60c6213000)

As long as this leads to crashes, I don't think we are doing anybody a
favor by defaulting to libguile-2.x .

I'll switch back explicitly to 1.8.

-- 
David Kastrup

Re: Patchy email

pat...@gnu.org writes:

> 23:42:58 (UTC) Begin LilyPond compile, previous commit at 
> bf6f650dbc16cb33181501eee2aca082a5a5e3ef
> 23:43:05 Merged staging, now at:  bf6f650dbc16cb33181501eee2aca082a5a5e3ef
> 23:43:06  Success:./autogen.sh --noconfigure
> 23:43:18  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 23:43:21  Success:nice make clean
> 23:46:54  Success:nice make -j9 CPU_COUNT=9
> 23:51:15  Success:nice make test -j9 CPU_COUNT=9
> 23:54:59 *** FAILED BUILD ***
>   nice make doc -j9 CPU_COUNT=9
>   Previous good commit:   825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>   Current broken commit:  bf6f650dbc16cb33181501eee2aca082a5a5e3ef
> 23:54:59 *** FAILED STEP ***
>   merge from staging
>   Failed runner: nice make doc -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
> 23:54:59 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 333, 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 doc -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt

So I am suddenly seeing comparatively frequent segfaults in my patchy
runs while building the docs.  This is the second time in as many days
(or not more than 3 days I guess).

My prime candidates are basically Han-Wen's job control for
lilypond-book (could lead to out-of-memory conditions on my system and I
don't think we handle exceptions other than aborting currently) and
Torsten Hämmerle's French beaming stuff.  I read through that patch a
few times but did not see any red flags.

To track this down, I'll now enable core dumps and hope that eventually
I'll be able to get a relevant one.  I'll stick at current settings for
now.

-- 
David Kastrup

Re: Patchy email

2020-03-05 Thread David Kastrup

David Kastrup  writes:

> pat...@gnu.org writes:
>
>> 23:08:39 (UTC) Begin LilyPond compile, previous commit at
>> 825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>> 23:08:41 Auto packing the repository in background for optimum performance.
>> See "git help gc" for manual housekeeping.
>> 23:08:47 Merged staging, now at: 825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>> 23:08:48 Success:./autogen.sh --noconfigure
>> 23:09:00 Success:/tmp/lilypond-autobuild/configure 
>> --enable-checking
>> 23:09:02 Success:nice make clean
>> 23:12:38 Success:nice make -j9 CPU_COUNT=9
>> 23:17:06 Success:nice make test -j9 CPU_COUNT=9
>> 23:31:48 *** FAILED BUILD ***
>>  nice make doc -j9 CPU_COUNT=9
>>  Previous good commit:   06b5ac8389b5cc3c9afbb2c84e2e5c02d0c9dca0
>>  Current broken commit:  825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>> 23:31:48 *** FAILED STEP ***
>>  merge from staging
>>  Failed runner: nice make doc -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>> 23:31:48 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 333, 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 doc -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>
> That one was actually a segfault.  Cannot plausibly come from my patch,
> so that is sort-of confusing.  I'll retry.

Succeeded on the second try.  I don't really believe in a hardware bug,
so it may be a Heisenbug instead.  Hopefully not something due to
unprotected SCM data structures in some earlier commit: it's not like we
haven't seen that kind of problem before.

-- 
David Kastrup

Re: Patchy email

2020-03-05 Thread David Kastrup

pat...@gnu.org writes:

> 23:08:39 (UTC) Begin LilyPond compile, previous commit at 
> 825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
> 23:08:41 Auto packing the repository in background for optimum performance.
> See "git help gc" for manual housekeeping.
> 23:08:47 Merged staging, now at:  825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
> 23:08:48  Success:./autogen.sh --noconfigure
> 23:09:00  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 23:09:02  Success:nice make clean
> 23:12:38  Success:nice make -j9 CPU_COUNT=9
> 23:17:06  Success:nice make test -j9 CPU_COUNT=9
> 23:31:48 *** FAILED BUILD ***
>   nice make doc -j9 CPU_COUNT=9
>   Previous good commit:   06b5ac8389b5cc3c9afbb2c84e2e5c02d0c9dca0
>   Current broken commit:  825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
> 23:31:48 *** FAILED STEP ***
>   merge from staging
>   Failed runner: nice make doc -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
> 23:31:48 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 333, 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 doc -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt

That one was actually a segfault.  Cannot plausibly come from my patch,
so that is sort-of confusing.  I'll retry.

-- 
David Kastrup

Patchy email

2020-03-05 Thread patchy

23:08:39 (UTC) Begin LilyPond compile, previous commit at   
825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
23:08:41 Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
23:08:47 Merged staging, now at:825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
23:08:48Success:./autogen.sh --noconfigure
23:09:00Success:/tmp/lilypond-autobuild/configure 
--enable-checking
23:09:02Success:nice make clean
23:12:38Success:nice make -j9 CPU_COUNT=9
23:17:06Success:nice make test -j9 CPU_COUNT=9
23:31:48 *** FAILED BUILD ***
nice make doc -j9 CPU_COUNT=9
Previous good commit:   06b5ac8389b5cc3c9afbb2c84e2e5c02d0c9dca0
Current broken commit:  825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
23:31:48 *** FAILED STEP ***
merge from staging
Failed runner: nice make doc -j9 CPU_COUNT=9
See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
23:31:48 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 
333, 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 doc -j9 CPU_COUNT=9
See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt

Patchy email

2020-02-18 Thread patchy

10:35:17 (UTC) Begin LilyPond compile, previous commit at   
b16c3d14f3d1f10aa919e70107e6103c67a9aa01
10:35:20 Merged staging, now at:b16c3d14f3d1f10aa919e70107e6103c67a9aa01
10:35:21Success:./autogen.sh --noconfigure
10:35:34Success:/tmp/lilypond-autobuild/configure 
--enable-checking
10:35:37Success:nice make clean
10:37:17 *** FAILED BUILD ***
nice make -j9 CPU_COUNT=9
Previous good commit:   ce072002412d48f48cc4ff4620d82f700e816225
Current broken commit:  b16c3d14f3d1f10aa919e70107e6103c67a9aa01
10:37:17 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
10:37:17 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 
316, 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 -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt

Re: Patchy email

2019-12-14 Thread David Kastrup

David Kastrup  writes:

> Knut Petersen  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.

20 weeks delay for a mail to reach the list must be some sort of
record.  Good thing that I had Knut in Cc.

-- 
David Kastrup

Re: Patchy email

2019-07-30 Thread Knut Petersen


On 30.07.19 01:39, David Kastrup wrote:


No, that make test needs a fix.  make test is supposed to test the
version in the work directory, not some weird amalgamate between system
installed version and work directory version.

Any idea what would be required here?


Yes.

https://codereview.appspot.com/560840043/
https://sourceforge.net/p/testlilyissues/issues/5544/

Knut

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-30 Thread Knut Petersen


On 30.07.19 01:39, David Kastrup wrote:


Stracing shows that after 'make all' it is also necessary to execute
'make install' prior to 'make test-baseline' or 'make test-clean'.

That's insane.  Having to install LilyPond before being able to test it
makes no sense.


During regression testing we use "musicxml2ly --out=- -". A strace log of such 
a run is in TC.18804.

   grep ^openat TC.18804 | grep -v ENOENT | grep /home/knut/sources | \
   sort | sed -e 's|[^"]*\"/home/knut/sources/lilybuilt|$PREFIX|'  \
   -e 's|[^"]*\"/home/knut/sources/lily/build|$BUILDDIR|' -e 's|\"[^"]*||' | 
uniq

results in

   $BUILDDIR/scripts/out/musicxml2ly
   $PREFIX/share/lilypond/2.21.0/python/lilylib.pyc
   $PREFIX/share/lilypond/2.21.0/python/lilylib.py
   $PREFIX/share/lilypond/2.21.0/python/musicexp.pyc
   $PREFIX/share/lilypond/2.21.0/python/musicexp.py
   $PREFIX/share/lilypond/2.21.0/python/musicxml2ly_conversion.pyc
   $PREFIX/share/lilypond/2.21.0/python/musicxml2ly_conversion.py
   $PREFIX/share/lilypond/2.21.0/python/musicxml.pyc
   $PREFIX/share/lilypond/2.21.0/python/musicxml.py
   $PREFIX/share/lilypond/2.21.0/python/rational.pyc
   $PREFIX/share/lilypond/2.21.0/python/rational.py
   $PREFIX/share/lilypond/2.21.0/python/utilities.pyc
   $PREFIX/share/lilypond/2.21.0/python/utilities.py

So only the musicxml2ly file is from the version to test, all the other python 
files are old.


If 'make install' is omitted, the result depends both on files from
the baseline version and on files that belong to the version of
lilypond that was last installed with the same prefix.

Then we need to fix that.


Yes.



If the process also succeeds on your system we would know that patchy
needs a fix.

No, that make test needs a fix.  make test is supposed to test the
version in the work directory, not some weird amalgamate between system
installed version and work directory version.

Any idea what would be required here?

The fastest 'fix' would be to compile with a prefix pointing into a subdirectory
of the build directory and installing into that prior to 'make test-baseline'.
But that is an ugly workaround. I'll have a look at the makefiles this night.

Knut
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

Knut Petersen  writes:

> On 29.07.19 17:55, David Kastrup wrote:
>> 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.
>
> In the chapter "Regtest comparison" of our contributor's guide we can read:
>
>Run |make|with current git master without any of your changes.
>Before making changes to the code, establish a baseline for the comparison 
> by going to the ‘$LILYPOND_GIT/build/’ directory and running:
>
>make test-baseline
>
> Stracing shows that after 'make all' it is also necessary to execute
> 'make install' prior to 'make test-baseline' or 'make test-clean'.

That's insane.  Having to install LilyPond before being able to test it
makes no sense.

> If 'make install' is omitted, the result depends both on files from
> the baseline version and on files that belong to the version of
> lilypond that was last installed with the same prefix.

Then we need to fix that.

> David, please rerun the test of my patch against origin/master on your
> system. On my system the process succeeds now:

> If the process also succeeds on your system we would know that patchy
> needs a fix.

No, that make test needs a fix.  make test is supposed to test the
version in the work directory, not some weird amalgamate between system
installed version and work directory version.

Any idea what would be required here?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-29 Thread Knut Petersen

On 29.07.19 17:55, David Kastrup wrote:

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.

In the chapter "Regtest comparison" of our contributor's guide we can read:

Run |make|with current git master without any of your changes.
Before making changes to the code, establish a baseline for the comparison
by going to the ‘$LILYPOND_GIT/build/’ directory and running:

make test-baseline

Stracing shows that after 'make all' it is also necessary to execute 'make install' prior to 'make test-baseline' or 'make test-clean'. If 'make install' is omitted, the result depends both on files from the baseline version and on files that belong to the version of lilypond that was last installed
with the same prefix.

David, please rerun the test of my patch against origin/master on your system.
On my system the process succeeds now:

exec*git clean -dfx *in /home/knut/sources/lily ... succeeded after 2
seconds
exec *git checkout origin/master* in /home/knut/sources/lily ...
succeeded after 0 seconds
Building LILYPOND origin/master (34a114b835b042537f598620ce41912f51dd4fa4)
...
exec *./autogen.sh --noconfigure* in /home/knut/sources/lily ...
succeeded after 0 seconds
exec *mkdir -p build* in /home/knut/sources/lily ... succeeded after 0
seconds
exec *cd /home/knut/sources/lily/build* in /home/knut/sources/lily ...
succeeded after 0 seconds
exec *../configure --prefix=/home/knut/sources/lilybuilt
--with-urwotf-dir=/home/knut/sources/urw-core35-fonts* in
/home/knut/sources/lily/build ... succeeded after 7 seconds
exec *make -j 11 CPU_COUNT=11 all* in /home/knut/sources/lily/build ...
succeeded after 137 seconds
exec *make -j 11 CPU_COUNT=11 install* in /home/knut/sources/lily/build
... succeeded after 2 seconds
exec *make -j 11 CPU_COUNT=11 test-baseline* in
/home/knut/sources/lily/build ... succeeded after 175 seconds
exec .*/make-regtest-pngs.sh -j9 -o* in
/home/knut/sources/lily/scripts/auxiliar ... succeeded after 71 seconds
exec *g**it checkout FIX_MUSICXML2LY* in /home/knut/sources/lily ...
succeeded after 0 seconds
Building LILYPOND FIX_MUSICXML2LY (9aae63f0e0adf31eeffe6e0cb11c0e5a22c9eae5)
...
exec .*/autogen.sh --noconfigure* in /home/knut/sources/lily ...
succeeded after 0 seconds
exec *mkdir -p build *in /home/knut/sources/lily ... succeeded after 0
seconds
exec *cd /home/knut/sources/lily/build* in /home/knut/sources/lily ...
succeeded after 0 seconds
exec *../configure --prefix=/home/knut/sources/lilybuilt
--with-urwotf-dir=/home/knut/sources/urw-core35-fonts* in
/home/knut/sources/lily/build ... succeeded after 7 seconds
exec *make -j 11 CPU_COUNT=11 all* in /home/knut/sources/lily/build ...
succeeded after 8 seconds
exec *make -j 11 CPU_COUNT=11 instal**l* in /home/knut/sources/lily/build
... succeeded after 5 seconds
exec *make -j 11 CPU_COUNT=11 test-clean* in
/home/knut/sources/lily/build ... succeeded after 0 seconds
exec *make -j 11 CPU_COUNT=11 check* in /home/knut/sources/lily/build ...
succeeded after 188 seconds
exec *./make-regtest-pngs.sh -j9 -n* in
/home/knut/sources/lily/scripts/auxiliar ... succeeded after 606 seconds
Total regression test time: 1208 seconds

If the process also succeeds on your system we would know that patchy needs a
fix.

Knut

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

Knut Petersen  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

Knut Petersen  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-29 Thread 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

David Kastrup  writes:

> Knut Petersen  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=
>> --with-urwotf-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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

Knut Petersen  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=
> --with-urwotf-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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-29 Thread Knut Petersen


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= 
--with-urwotf-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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-27 Thread David Kastrup

James  writes:

> Hello,
>
> On 27/07/2019 10:10, David Kastrup wrote:
>> James  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-27 Thread James


Hello,

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

James  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-27 Thread David Kastrup

James  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 
Date:   Tue May 19 10:21:13 2015 +0200

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

commit 6d784e9a2c5e7f0f1baf6cd500459504be51826e
Author: David Kastrup 
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-27 Thread James

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-27 Thread David Kastrup

Knut Petersen  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.00  -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.00) (* 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:

Re: Patchy email

2019-07-27 Thread 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

Knut Petersen  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-26 Thread 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

James  writes:

> Hello,
>
> On 26/07/2019 16:13, David Kastrup wrote:
>> David Kastrup  writes:
>>
>>> David Kastrup  writes:
>>>
 fatal: Not a valid object name master

 Apparently, the patch from
 commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
 Author: Knut Petersen 
 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  - /3 days ago /
> 
>
> Optimize tree.gittxt messages master staging
> author  Knut Petersen 
> Sun, 7 Jul 2019 12:16:05 +0100 (13:16 +0200)
> committer   Knut Petersen 
> 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-07-26 Thread James


Hello,

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

David Kastrup  writes:


David Kastrup  writes:


fatal: Not a valid object name master

Apparently, the patch from
commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
Author: Knut Petersen 
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  - /3 days ago /


Optimize tree.gittxt messages master staging
author  Knut Petersen 
Sun, 7 Jul 2019 12:16:05 +0100 (13:16 +0200)
committer   Knut Petersen 
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

pat...@gnu.org writes:

> 15:04:59 (UTC) Begin LilyPond compile, previous commit at 
> 95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:05:03 Merged staging, now at:  95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:05:03  Success:./autogen.sh --noconfigure
> 15:05:19  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 15:05:22  Success:nice make clean
> 15:09:28  Success:nice make -j9 CPU_COUNT=9
> 15:12:41 *** FAILED BUILD ***
>   nice make test -j9 CPU_COUNT=9
>   Previous good commit:   7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>   Current broken commit:  95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:12:41 *** 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
> 15:12:41 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
>

This fails in multiple musicxml-converted files.  It's not clear to me
just why from the logs.  I am backing out

commit 1c51a616e289fffb918942c8f1e189ab50809157
Author: Knut Petersen 
Date:   Fri Jul 19 00:05:00 2019 +0200

Fix musicxml2ly.py / Python 2.4.5 incompatibility

In LilyPond 2.19.44 code was introduced that
improved musicxml2ly. Unfortunately, the new
code introduced a dependency on Python 2.7+,
although our installers only provide the
ancient Python 2.4.5.

If our Python 2.4.5 was used to interpret
musicxml2ly, some parts of the generated
lilypond source file were ok, in other parts
every character was paired with an additional
NUL byte. This commit fixes that problem
by adding '.encode('utf-8')' at some places.

A 2nd problem was that str.format() was
used. Unfortunately, str.format() is only
available in python 2.6+. The patch replaces
affected code with syntax compatible to our
Python 2.4.5.

from staging in order to try again.  If you cannot reproduce, I'll try
to see whether I can figure out more after patchy finishes with the
previous revert.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2019-07-26 Thread patchy

15:04:59 (UTC) Begin LilyPond compile, previous commit at   
95a26f04acfa14068edff2d4457bfeca12ad80fc
15:05:03 Merged staging, now at:95a26f04acfa14068edff2d4457bfeca12ad80fc
15:05:03Success:./autogen.sh --noconfigure
15:05:19Success:/tmp/lilypond-autobuild/configure 
--enable-checking
15:05:22Success:nice make clean
15:09:28Success:nice make -j9 CPU_COUNT=9
15:12:41 *** FAILED BUILD ***
nice make test -j9 CPU_COUNT=9
Previous good commit:   7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
Current broken commit:  95a26f04acfa14068edff2d4457bfeca12ad80fc
15:12:41 *** 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
15:12:41 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

David Kastrup  writes:

> David Kastrup  writes:
>
>> fatal: Not a valid object name master
>>
>> Apparently, the patch from
>> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>> Author: Knut Petersen 
>> 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

David Kastrup  writes:

> pat...@gnu.org 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 
> 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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

pat...@gnu.org 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 
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2019-07-26 Thread patchy

14:39:40 (UTC) Begin LilyPond compile, previous commit at   
1c51a616e289fffb918942c8f1e189ab50809157
14:39:51 Merged staging, now at:1c51a616e289fffb918942c8f1e189ab50809157
14:39:52Success:./autogen.sh --noconfigure
14:40:08Success:/tmp/lilypond-autobuild/configure 
--enable-checking
14:40:11Success:nice make clean
14:44:20Success: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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-06-13 Thread James Lowe

David,

On Thu, 13 Jun 2019 10:03:41 +0200, David Kastrup  wrote:

> James   writes:
> 
> > David,
> >
> > Revert the commit if its easier. I'll figure it out this evening when
> > I get home. It's probably some oversight or a makelsr issue.
> >
> > Sorry.
> 
> Ah, this was a third-party commit by you.  

Actually no. It was a patch I created (git format-patch) based on text sent to 
me by Adam (I credited him as the author because he did most of the leg work). 
So whatever is going on here is completely my fault.

Again, sorry. As I am at work I cannot figure it out now, but not to worry, 
I'll take a look again at home.

Regards

James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-06-13 Thread David Kastrup

James   writes:

> David,
>
> Revert the commit if its easier. I'll figure it out this evening when
> I get home. It's probably some oversight or a makelsr issue.
>
> Sorry.

Ah, this was a third-party commit by you.  The most frequent error here
is to apply a provided patch with

git apply xxx.patch

instead of

git apply --index xxx.patch

(only the latter will add new files to the repository).  However, given
that there also is a large commit message with a significantly different
AuthorDate than the CommitDate, it is more likely that this was applied
and tested as a complete commit using

git am ...

So I don't really know.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Re: Patchy email

2019-06-13 Thread James


David,

Revert the commit if its easier. I'll figure it out this evening when I get 
home. It's probably some oversight or a makelsr issue.

Sorry.

Thu Jun 13 08:35:24 GMT+01:00 2019 David Kastrup :

> David Kastrup  writes:
>
> > pat...@gnu.org writes:
> >
> >> 07:02:37 (UTC) Begin LilyPond compile, previous commit at 
> >> 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> >> 07:02:40 Merged staging, now at: 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> >> 07:02:41 Success: ./autogen.sh --noconfigure
> >> 07:02:57 Success: /tmp/lilypond-autobuild/configure --enable-checking
> >> 07:02:59 Success: nice make clean
> >> 07:06:51 *** FAILED BUILD ***
> >> nice make -j9 CPU_COUNT=9
> >> Previous good commit: 1272e45b49fb91fb5fd181b7d045a0ac4d662450
> >> Current broken commit: 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> >> 07:06:51 *** FAILED STEP ***
> >> merge from staging
> >> Failed runner: nice make -j9 CPU_COUNT=9
> >> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
> >> 07:06:51 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 316, 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 -j9 CPU_COUNT=9
> >> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
> >
> > The relevant line:
> >
> > lilypond-book.py: error: file not found: turkish-makam-example.ly
> >
> > Most likely this built on the committer's computer because this file was
> > locally present but not checked into the version control system.
> >
> > I'll be backing that commit out of staging.
>
> Did so. Though I am puzzled how the original commit had been able to
> pass patchy testing when it had that problem. Is the pushed version
> different than the tested one? If so, how did that happen?
>
> --
> David Kastrup
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-06-13 Thread David Kastrup

David Kastrup  writes:

> pat...@gnu.org writes:
>
>> 07:02:37 (UTC) Begin LilyPond compile, previous commit at
>> 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
>> 07:02:40 Merged staging, now at: 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
>> 07:02:41 Success:./autogen.sh --noconfigure
>> 07:02:57 Success:/tmp/lilypond-autobuild/configure 
>> --enable-checking
>> 07:02:59 Success:nice make clean
>> 07:06:51 *** FAILED BUILD ***
>>  nice make -j9 CPU_COUNT=9
>>  Previous good commit:   1272e45b49fb91fb5fd181b7d045a0ac4d662450
>>  Current broken commit:  52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
>> 07:06:51 *** FAILED STEP ***
>>  merge from staging
>>  Failed runner: nice make -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
>> 07:06:51 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 316, 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 -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
>
> The relevant line:
>
> lilypond-book.py: error: file not found: turkish-makam-example.ly
>
> Most likely this built on the committer's computer because this file was
> locally present but not checked into the version control system.
>
> I'll be backing that commit out of staging.

Did so.  Though I am puzzled how the original commit had been able to
pass patchy testing when it had that problem.  Is the pushed version
different than the tested one?  If so, how did that happen?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2019-06-13 Thread David Kastrup

pat...@gnu.org writes:

> 07:02:37 (UTC) Begin LilyPond compile, previous commit at 
> 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> 07:02:40 Merged staging, now at:  52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> 07:02:41  Success:./autogen.sh --noconfigure
> 07:02:57  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 07:02:59  Success:nice make clean
> 07:06:51 *** FAILED BUILD ***
>   nice make -j9 CPU_COUNT=9
>   Previous good commit:   1272e45b49fb91fb5fd181b7d045a0ac4d662450
>   Current broken commit:  52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> 07:06:51 *** FAILED STEP ***
>   merge from staging
>   Failed runner: nice make -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
> 07:06:51 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 316, 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 -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt

The relevant line:

lilypond-book.py: error: file not found: turkish-makam-example.ly

Most likely this built on the committer's computer because this file was
locally present but not checked into the version control system.

I'll be backing that commit out of staging.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2019-06-13 Thread patchy

07:02:37 (UTC) Begin LilyPond compile, previous commit at   
52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
07:02:40 Merged staging, now at:52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
07:02:41Success:./autogen.sh --noconfigure
07:02:57Success:/tmp/lilypond-autobuild/configure 
--enable-checking
07:02:59Success:nice make clean
07:06:51 *** FAILED BUILD ***
nice make -j9 CPU_COUNT=9
Previous good commit:   1272e45b49fb91fb5fd181b7d045a0ac4d662450
Current broken commit:  52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
07:06:51 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
07:06:51 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 
316, 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 -j9 CPU_COUNT=9
See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2018-06-19 Thread David Kastrup

"James Lowe"  writes:

> David

>> Thats the musicxml2ly thing again.  I now locally did make & make
>> install now and restarted to see whether this still breaks.
>> 
>> We probably need to make sure to use the right versions of
>> musicxml2ly (the ones in the build tree rather than the installed
>> ones) in all respects. This failed build appears to be because of
>> some module being taken from the installed version rather than the
>> build tree.  I expect the next run to go through, but this makes
>> tests non-representative.
>> 
>> --
> [James:] I don't understand. I don't have this problem. Are you saying that
> your patchy is not building LP from the same 'tree' as you are testing the
> patch from?

No.  I am saying that my patchy uses some scraps of the currently
installed musicxml2ly version rather than using everything from the
build tree.  Your tests are likely immune against this problem because
you don't have any installed version of LilyPond (and musicxml2ly) in
the VMs where you do the building and apparently that is enough to make
sure this problem does not happen: the build appears to find the
musicxml2ly stuff in the build tree as long as no installed version
exists that it could take instead.

> I am always a bit confused when I don't get the same problem as others
> that run the scripts I do.

As I predicted, this problem disappeared after I did make && sudo make
install .  But it means that the parts of the test involving musicxml2ly
might yield false negatives _or_ false positives when there is an
installed version of musicxml2ly around.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

RE: Patchy email

2018-06-19 Thread James Lowe

David

> -Original Message-
> From: lilypond-devel 
> On Behalf Of David Kastrup
> Sent: 19 June 2018 11:51
> To: pat...@gnu.org
> Cc: lilypond-devel@gnu.org
> Subject: Re: Patchy email
> 
> pat...@gnu.org writes:
> 
> > 10:01:55 (UTC) Begin LilyPond compile, previous commit at
>   f3279a829a6eb5c009440f39de15c0104b038b7c
> > 10:02:00 Merged staging, now at:
>   f3279a829a6eb5c009440f39de15c0104b038b7c
> > 10:02:01Success:./autogen.sh --noconfigure
> > 10:02:15Success:/tmp/lilypond-autobuild/configure --
> enable-checking
> > 10:02:18Success:nice make clean
> > 10:08:14Success:nice make -j5 CPU_COUNT=5
> > 10:13:11Success:nice make test -j5 CPU_COUNT=5
> > 10:19:52 *** FAILED BUILD ***
> > nice make doc -j5 CPU_COUNT=5
> > Previous good commit:
>   aec018d7d4ed58e6d67e4621019a6cf2936b212f
> > Current broken commit:
>   f3279a829a6eb5c009440f39de15c0104b038b7c
> > 10:19:52 *** FAILED STEP ***
> > merge from staging
> > Failed runner: nice make doc -j5 CPU_COUNT=5 See the log file
> > log-staging-nice-make-doc--j5-CPU_COUNT=5.txt
> > 10:19:52 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 333, 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 doc -j5 CPU_COUNT=5 See the
> > log file log-staging-nice-make-doc--j5-CPU_COUNT=5.txt
> 
> Thats the musicxml2ly thing again.  I now locally did make & make install
now
> and restarted to see whether this still breaks.
> 
> We probably need to make sure to use the right versions of musicxml2ly
(the
> ones in the build tree rather than the installed ones) in all respects.
This failed
> build appears to be because of some module being taken from the installed
> version rather than the build tree.  I expect the next run to go through,
but this
> makes tests non-representative.
> 
> --
[James:] I don't understand. I don't have this problem. Are you saying that
your patchy is not building LP from the same 'tree' as you are testing the
patch from?

I am always a bit confused when I don't get the same problem as others that
run the scripts I do.

Thanks for your time.

James


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2018-06-19 Thread David Kastrup

pat...@gnu.org writes:

> 10:01:55 (UTC) Begin LilyPond compile, previous commit at 
> f3279a829a6eb5c009440f39de15c0104b038b7c
> 10:02:00 Merged staging, now at:  f3279a829a6eb5c009440f39de15c0104b038b7c
> 10:02:01  Success:./autogen.sh --noconfigure
> 10:02:15  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 10:02:18  Success:nice make clean
> 10:08:14  Success:nice make -j5 CPU_COUNT=5
> 10:13:11  Success:nice make test -j5 CPU_COUNT=5
> 10:19:52 *** FAILED BUILD ***
>   nice make doc -j5 CPU_COUNT=5
>   Previous good commit:   aec018d7d4ed58e6d67e4621019a6cf2936b212f
>   Current broken commit:  f3279a829a6eb5c009440f39de15c0104b038b7c
> 10:19:52 *** FAILED STEP ***
>   merge from staging
>   Failed runner: nice make doc -j5 CPU_COUNT=5
> See the log file log-staging-nice-make-doc--j5-CPU_COUNT=5.txt
> 10:19:52 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 333, 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 doc -j5 CPU_COUNT=5
> See the log file log-staging-nice-make-doc--j5-CPU_COUNT=5.txt

Thats the musicxml2ly thing again.  I now locally did make & make
install now and restarted to see whether this still breaks.

We probably need to make sure to use the right versions of musicxml2ly
(the ones in the build tree rather than the installed ones) in all
respects.  This failed build appears to be because of some module being
taken from the installed version rather than the build tree.  I expect
the next run to go through, but this makes tests non-representative.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2018-06-19 Thread patchy

10:01:55 (UTC) Begin LilyPond compile, previous commit at   
f3279a829a6eb5c009440f39de15c0104b038b7c
10:02:00 Merged staging, now at:f3279a829a6eb5c009440f39de15c0104b038b7c
10:02:01Success:./autogen.sh --noconfigure
10:02:15Success:/tmp/lilypond-autobuild/configure 
--enable-checking
10:02:18Success:nice make clean
10:08:14Success:nice make -j5 CPU_COUNT=5
10:13:11Success:nice make test -j5 CPU_COUNT=5
10:19:52 *** FAILED BUILD ***
nice make doc -j5 CPU_COUNT=5
Previous good commit:   aec018d7d4ed58e6d67e4621019a6cf2936b212f
Current broken commit:  f3279a829a6eb5c009440f39de15c0104b038b7c
10:19:52 *** FAILED STEP ***
merge from staging
Failed runner: nice make doc -j5 CPU_COUNT=5
See the log file log-staging-nice-make-doc--j5-CPU_COUNT=5.txt
10:19:52 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 
333, 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 doc -j5 CPU_COUNT=5
See the log file log-staging-nice-make-doc--j5-CPU_COUNT=5.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2018-06-18 Thread patchy

11:52:14 (UTC) Begin LilyPond compile, previous commit at   
fdab8053c4fbfadf38867f7d14769d227ce26749
11:52:24 Merged staging, now at:fdab8053c4fbfadf38867f7d14769d227ce26749
11:52:24Success:./autogen.sh --noconfigure
11:52:39Success:/tmp/lilypond-autobuild/configure 
--enable-checking
11:52:41Success:nice make clean
11:59:01Success:nice make -j5 CPU_COUNT=5
12:04:07Success:nice make test -j5 CPU_COUNT=5
12:11:12 *** FAILED BUILD ***
nice make doc -j5 CPU_COUNT=5
Previous good commit:   aec018d7d4ed58e6d67e4621019a6cf2936b212f
Current broken commit:  fdab8053c4fbfadf38867f7d14769d227ce26749
12:11:12 *** FAILED STEP ***
merge from staging
Failed runner: nice make doc -j5 CPU_COUNT=5
See the log file log-staging-nice-make-doc--j5-CPU_COUNT=5.txt
12:11:12 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 
333, 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 doc -j5 CPU_COUNT=5
See the log file log-staging-nice-make-doc--j5-CPU_COUNT=5.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2016-10-02 Thread David Kastrup

pat...@gnu.org writes:

> 15:20:22 (UTC) Begin LilyPond compile, previous commit at 
> 65aaa35a119053e92a608fbedceb20762787d21b
> 15:20:27 Merged staging, now at:  65aaa35a119053e92a608fbedceb20762787d21b
> 15:20:28  Success:./autogen.sh --noconfigure
> 15:20:36 *** FAILED BUILD ***
>   /tmp/lilypond-autobuild/configure --enable-checking
>   Previous good commit:   8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
>   Current broken commit:  65aaa35a119053e92a608fbedceb20762787d21b
> 15:20:36 *** FAILED STEP ***
>   merge from staging
>   Failed runner: /tmp/lilypond-autobuild/configure --enable-checking
> See the log file log-staging-configure.txt
> 15:20:36 Traceback (most recent call last):
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 527, in handle_staging
> self.configure (issue_id)
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 300, in configure
> issue_id, "configure", env=dict (config.items ("configure_environment")))
>   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: /tmp/lilypond-autobuild/configure 
> --enable-checking
> See the log file log-staging-configure.txt

Ugh.  Forget this and the previous (but simultaneously sent from my mail
queue) mail.  That's what happens when I configure (incompletely) back
and forth between amd64 architecture and i386 architecture in order to
check out code generation problems.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2016-10-02 Thread patchy

15:20:22 (UTC) Begin LilyPond compile, previous commit at   
65aaa35a119053e92a608fbedceb20762787d21b
15:20:27 Merged staging, now at:65aaa35a119053e92a608fbedceb20762787d21b
15:20:28Success:./autogen.sh --noconfigure
15:20:36 *** FAILED BUILD ***
/tmp/lilypond-autobuild/configure --enable-checking
Previous good commit:   8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
Current broken commit:  65aaa35a119053e92a608fbedceb20762787d21b
15:20:36 *** FAILED STEP ***
merge from staging
Failed runner: /tmp/lilypond-autobuild/configure --enable-checking
See the log file log-staging-configure.txt
15:20:36 Traceback (most recent call last):
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
527, in handle_staging
self.configure (issue_id)
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
300, in configure
issue_id, "configure", env=dict (config.items ("configure_environment")))
  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: /tmp/lilypond-autobuild/configure 
--enable-checking
See the log file log-staging-configure.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2016-10-02 Thread patchy

15:03:41 (UTC) Begin LilyPond compile, previous commit at   
65aaa35a119053e92a608fbedceb20762787d21b
15:03:46 Merged staging, now at:65aaa35a119053e92a608fbedceb20762787d21b
15:03:47Success:./autogen.sh --noconfigure
15:04:03Success:/tmp/lilypond-autobuild/configure 
--enable-checking
15:04:06Success:nice make clean
15:11:55 *** FAILED BUILD ***
nice make -j3 CPU_COUNT=3
Previous good commit:   8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
Current broken commit:  65aaa35a119053e92a608fbedceb20762787d21b
15:11:55 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
15:11:55 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 
316, 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 -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2016-10-01 Thread James


Jean-Charles,


On 01/10/16 12:59, Jean-Charles Malahieude wrote:

Le 28/09/2016 à 13:23, James a écrit :


Now if only Jean-Charles, Graham et al, could script checking reg
test diffs and finding obscure make errors in all the .log files we
generate ;)



I'm not good at all with scripting, but could try to track down the 
logs. What would you like me to do in this area ?


Cheers,
Jean-Charles



Don't worry, I was just making a (now obviously poor) joke

%^)

I thought it was you and others that created the Patchy scripts, so 
maybe I got you mixed up with one of the other developers.


Have a good weekend.

james

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2016-10-01 Thread Jean-Charles Malahieude


Le 28/09/2016 à 13:23, James a écrit :


Now if only Jean-Charles, Graham et al, could script checking reg
test diffs and finding obscure make errors in all the .log files we
generate ;)



I'm not good at all with scripting, but could try to track down the 
logs. What would you like me to do in this area ?


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2016-09-28 Thread James




On 28/09/16 10:24, David Kastrup wrote:

pat...@gnu.org writes:


07:29:54 (UTC) Begin LilyPond compile, previous commit at   
8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
07:29:58 Merged staging, now at:8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
07:29:59Success:./autogen.sh --noconfigure
07:30:16Success:/tmp/lilypond-autobuild/configure 
--enable-checking
07:30:18Success:nice make clean
07:40:20Success:nice make -j3 CPU_COUNT=3
07:50:03Success:nice make test -j3 CPU_COUNT=3
08:54:44Success:nice make doc -j3 CPU_COUNT=3
08:56:12 *** FAILED STEP ***
merge from staging
Command '['git', 'fetch']' returned non-zero exit status 128
ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
08:56:12 Traceback (most recent call last):
   File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
530, in handle_staging
 self.merge_push ()
   File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
469, in merge_push
 run ("git fetch")
   File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
105, in run
 raise FailedCommand ("Command '%s' returned non-zero exit status %d\n%s" % 
(cmd, returncode, stderr.strip ()))
FailedCommand: Command '['git', 'fetch']' returned non-zero exit status 128
ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Intermittent net failure.  I took the liberty of still counting this as
success and manually pushing this staging to master.

Surprising how "dangerous" the manual completion of this Patchy run
feels after a few years of our automated procedure.

Well it is pretty robust, you'd be surprised how many times I get these 
kinds of errors over a month (due to repo/network issues).


I've never seen a partial push/merge it fails or it doesn't and if it 
fails, then patchy clears up any stale 'lock' branches and starts over.


I'm impressed just how resilient these scripts have been :)

Now if only Jean-Charles, Graham et al, could script checking reg test 
diffs and finding obscure make errors in all the .log files we generate ;)


James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2016-09-28 Thread David Kastrup

pat...@gnu.org writes:

> 07:29:54 (UTC) Begin LilyPond compile, previous commit at 
> 8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
> 07:29:58 Merged staging, now at:  8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
> 07:29:59  Success:./autogen.sh --noconfigure
> 07:30:16  Success:/tmp/lilypond-autobuild/configure 
> --enable-checking
> 07:30:18  Success:nice make clean
> 07:40:20  Success:nice make -j3 CPU_COUNT=3
> 07:50:03  Success:nice make test -j3 CPU_COUNT=3
> 08:54:44  Success:nice make doc -j3 CPU_COUNT=3
> 08:56:12 *** FAILED STEP ***
>   merge from staging
>   Command '['git', 'fetch']' returned non-zero exit status 128
> ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> 08:56:12 Traceback (most recent call last):
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 530, in handle_staging
> self.merge_push ()
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 469, in merge_push
> run ("git fetch")
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 105, in run
> raise FailedCommand ("Command '%s' returned non-zero exit status %d\n%s" 
> % (cmd, returncode, stderr.strip ()))
> FailedCommand: Command '['git', 'fetch']' returned non-zero exit status 128
> ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.

Intermittent net failure.  I took the liberty of still counting this as
success and manually pushing this staging to master.

Surprising how "dangerous" the manual completion of this Patchy run
feels after a few years of our automated procedure.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

2016-09-28 Thread patchy

07:29:54 (UTC) Begin LilyPond compile, previous commit at   
8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
07:29:58 Merged staging, now at:8a493b7bc9aa4d34cd2970fc2223ec6920f0ed02
07:29:59Success:./autogen.sh --noconfigure
07:30:16Success:/tmp/lilypond-autobuild/configure 
--enable-checking
07:30:18Success:nice make clean
07:40:20Success:nice make -j3 CPU_COUNT=3
07:50:03Success:nice make test -j3 CPU_COUNT=3
08:54:44Success:nice make doc -j3 CPU_COUNT=3
08:56:12 *** FAILED STEP ***
merge from staging
Command '['git', 'fetch']' returned non-zero exit status 128
ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
08:56:12 Traceback (most recent call last):
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
530, in handle_staging
self.merge_push ()
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
469, in merge_push
run ("git fetch")
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
105, in run
raise FailedCommand ("Command '%s' returned non-zero exit status %d\n%s" % 
(cmd, returncode, stderr.strip ()))
FailedCommand: Command '['git', 'fetch']' returned non-zero exit status 128
ssh: Could not resolve hostname git.sv.gnu.org: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

14:30:36 (UTC) Begin LilyPond compile, previous commit at   
905109ea0e90efa8d9c1ba02769e458a0707cc47
14:30:42 Merged staging, now at:905109ea0e90efa8d9c1ba02769e458a0707cc47
14:30:43Success:./autogen.sh --noconfigure
14:30:56Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
14:30:59Success:nice make clean
14:31:00 *** FAILED BUILD ***
nice make -j3 CPU_COUNT=3
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  905109ea0e90efa8d9c1ba02769e458a0707cc47
14:31:00 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
14:31:00 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 
316, 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 -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2016-05-31 Thread David Kastrup

pat...@gnu.org writes:

> 10:35:41 (UTC) Begin LilyPond compile, previous commit at 
> def633f7a88fe8950b685adee93165c42299bd5c
> 10:35:55 Merged staging, now at:  def633f7a88fe8950b685adee93165c42299bd5c
> 10:35:56  Success:./autogen.sh --noconfigure
> 10:36:13  Success:/tmp/lilypond-autobuild/configure 
> --disable-optimising
> 10:36:17  Success:nice make clean
> 10:42:40  Success:nice make -j3 CPU_COUNT=3
> 10:50:35 *** FAILED BUILD ***
>   nice make test -j3 CPU_COUNT=3
>   Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
>   Current broken commit:  def633f7a88fe8950b685adee93165c42299bd5c
> 10:50:35 *** FAILED STEP ***
>   merge from staging
>   Failed runner: nice make test -j3 CPU_COUNT=3
> See the log file log-staging-nice-make-test--j3-CPU_COUNT=3.txt
> 10:50:35 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 -j3 CPU_COUNT=3
> See the log file log-staging-nice-make-test--j3-CPU_COUNT=3.txt

Ugh.  The Python module.  If I compile that with 64bit, it won't
cooperate with my 32bit Python2.7.  And half the desktop environment
depends on that so I don't want to swap that out.

I have to see whether I can make a clean 64/32 split along the necessary
lines here.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

10:35:41 (UTC) Begin LilyPond compile, previous commit at   
def633f7a88fe8950b685adee93165c42299bd5c
10:35:55 Merged staging, now at:def633f7a88fe8950b685adee93165c42299bd5c
10:35:56Success:./autogen.sh --noconfigure
10:36:13Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
10:36:17Success:nice make clean
10:42:40Success:nice make -j3 CPU_COUNT=3
10:50:35 *** FAILED BUILD ***
nice make test -j3 CPU_COUNT=3
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  def633f7a88fe8950b685adee93165c42299bd5c
10:50:35 *** FAILED STEP ***
merge from staging
Failed runner: nice make test -j3 CPU_COUNT=3
See the log file log-staging-nice-make-test--j3-CPU_COUNT=3.txt
10:50:35 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 -j3 CPU_COUNT=3
See the log file log-staging-nice-make-test--j3-CPU_COUNT=3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

10:02:01 (UTC) Begin LilyPond compile, previous commit at   
dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
10:02:05 Merged staging, now at:dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
10:02:06Success:./autogen.sh --noconfigure
10:02:25Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
10:02:28Success:nice make clean
10:02:31 *** FAILED BUILD ***
nice make -j3 CPU_COUNT=3
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
10:02:31 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
10:02:31 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 
316, 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 -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

09:52:20 (UTC) Begin LilyPond compile, previous commit at   
dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:52:24 Merged staging, now at:dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:52:25Success:./autogen.sh --noconfigure
09:52:39Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
09:52:42Success:nice make clean
09:52:43 *** FAILED BUILD ***
nice make -j3 CPU_COUNT=3
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:52:43 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
09:52:43 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 
316, 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 -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

09:47:21 (UTC) Begin LilyPond compile, previous commit at   
dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:47:25 Merged staging, now at:dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:47:26Success:./autogen.sh --noconfigure
09:47:40Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
09:47:44Success:nice make clean
09:47:45 *** FAILED BUILD ***
nice make -j3 CPU_COUNT=3
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:47:45 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
09:47:45 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 
316, 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 -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

09:34:56 (UTC) Begin LilyPond compile, previous commit at   
dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:35:10 Merged staging, now at:dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:35:11Success:./autogen.sh --noconfigure
09:35:11 *** FAILED BUILD ***
/tmp/lilypond-autobuild/configure --disable-optimising
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:35:11 *** FAILED STEP ***
merge from staging
Failed runner: /tmp/lilypond-autobuild/configure --disable-optimising
See the log file log-staging-configure.txt
09:35:11 Traceback (most recent call last):
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
527, in handle_staging
self.configure (issue_id)
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
300, in configure
issue_id, "configure", env=dict (config.items ("configure_environment")))
  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: /tmp/lilypond-autobuild/configure 
--disable-optimising
See the log file log-staging-configure.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

09:38:31 (UTC) Begin LilyPond compile, previous commit at   
dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:38:35 Merged staging, now at:dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:38:36Success:./autogen.sh --noconfigure
09:38:54Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
09:38:57Success:nice make clean
09:44:51 *** FAILED BUILD ***
nice make -j3 CPU_COUNT=3
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:44:51 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
09:44:51 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 
316, 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 -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email

09:33:49 (UTC) Begin LilyPond compile, previous commit at   
dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:33:54 Merged staging, now at:dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:33:54Success:./autogen.sh --noconfigure
09:33:55 *** FAILED BUILD ***
/tmp/lilypond-autobuild/configure --disable-optimising
Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
Current broken commit:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
09:33:55 *** FAILED STEP ***
merge from staging
Failed runner: /tmp/lilypond-autobuild/configure --disable-optimising
See the log file log-staging-configure.txt
09:33:55 Traceback (most recent call last):
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
527, in handle_staging
self.configure (issue_id)
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
300, in configure
issue_id, "configure", env=dict (config.items ("configure_environment")))
  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: /tmp/lilypond-autobuild/configure 
--disable-optimising
See the log file log-staging-configure.txt

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

2016-05-31 Thread David Kastrup

pat...@gnu.org writes:

> 09:14:55 (UTC) Begin LilyPond compile, previous commit at 
> dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
> 09:15:08 test-master-lock and PID entry exist but previous Patchy
> run (PID 17333) died, resetting test-master-lock anyway.
> 09:15:10 Merged staging, now at:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
> 09:15:11  Success:./autogen.sh --noconfigure
> 09:15:19 *** FAILED BUILD ***
>   /tmp/lilypond-autobuild/configure --disable-optimising
>   Previous good commit:   a1467ba6de6240dda93009c907b05794ec9b8d54
>   Current broken commit:  dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
> 09:15:19 *** FAILED STEP ***
>   merge from staging
>   Failed runner: /tmp/lilypond-autobuild/configure --disable-optimising
> See the log file log-staging-configure.txt
> 09:15:19 Traceback (most recent call last):
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 527, in handle_staging
> self.configure (issue_id)
>   File 
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
> line 300, in configure
> issue_id, "configure", env=dict (config.items ("configure_environment")))
>   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: /tmp/lilypond-autobuild/configure 
> --disable-optimising
> See the log file log-staging-configure.txt

Ugh, sorry for that.  I need to tell my patchy to compile for 64bit or
it will not get along with the libraries.  Let's see whether I manage to
do so.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy email