Re: GUB lilypond build fails

2019-01-01 Thread Werner LEMBERG


>> Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also;
>> I'm going to submit fontconfig changes to gub that rely on the
>> availability of this feature.
> 
> Well, I am not happy with such fresh changes in the stable-2.20
> branch but a 2.20 that we don't manage to get through GUB is
> pointless.  So also done.

Thanks!


Werner

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


Re: GUB lilypond build fails

2018-12-31 Thread David Kastrup
Werner LEMBERG  writes:

>>> cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master
>>> fixes that.
>> 
>> Of course (change to Python 2.4 syntax).  Done.
>
> Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also; I'm
> going to submit fontconfig changes to gub that rely on the
> availability of this feature.

Well, I am not happy with such fresh changes in the stable-2.20 branch
but a 2.20 that we don't manage to get through GUB is pointless.  So
also done.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-31 Thread Werner LEMBERG


>> cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master
>> fixes that.
> 
> Of course (change to Python 2.4 syntax).  Done.

Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also; I'm
going to submit fontconfig changes to gub that rely on the
availability of this feature.


Werner

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


Re: GUB lilypond build fails

2018-12-30 Thread David Kastrup
Knut Petersen  writes:

> On 30.12.18 19:31, Phil Holmes wrote:
>>
>>
>> Success building from master. Thanks Werner.  Will take me a time to
>> sort out a build from the stable candidate, but it looks like we're
>> on track.
>
> stable/2.20 currently will not build with gub.
>
> cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master fixes 
> that.

Of course (change to Python 2.4 syntax).  Done.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-30 Thread Knut Petersen

On 30.12.18 19:31, Phil Holmes wrote:



Success building from master. Thanks Werner.  Will take me a time to sort out a 
build from the stable candidate, but it looks like we're on track.


stable/2.20 currently will not build with gub.

cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master fixes that.




make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads...


i7-4790K: About 130 minutes for 'make lilypond' after an 'rm -rf target/*'

Knut

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


Re: GUB lilypond build fails

2018-12-30 Thread David Kastrup
"Phil Holmes"  writes:

> - Original Message - 
> From: "David Kastrup" 
> To: "Phil Holmes" 
> Cc: "Werner LEMBERG" ; 
> Sent: Sunday, December 30, 2018 6:46 PM
> Subject: Re: GUB lilypond build fails
>
>
>> "Phil Holmes"  writes:
>>
>>> - Original Message - 
>>> From: "Phil Holmes" 
>>> To: "Werner LEMBERG" 
>>> Cc: ; 
>>> Sent: Sunday, December 30, 2018 12:29 PM
>>> Subject: Re: GUB lilypond build fails
>>>
>>>
>>>>
>>>> The problem with "NewGub" would seem to be my issue.  I've always
>>>> made and uploaded GUB in a VM with a user gub and a directory called
>>>> NewGub under that user's home directory.  I'm currently trying to
>>>> build from a user with a home directory called gubd and in a
>>>> directory called GubDir.  I do have a user called gub (it's where
>>>> the VM lives) and could create a directory called NewGub and try to
>>>> see if this works at this time.  Watch this space.
>>>
>>>
>>> Success building from master. Thanks Werner.  Will take me a time to
>>> sort out a build from the stable candidate, but it looks like we're on
>>> track.
>>>
>>> make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads...
>>
>> That does not say a lot without specifying the generation.  I have in my
>> laptop a
>>
>> model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
>
>
> core i7-2600 3.4GHz.  About 8 years old

Oh, 2nd generation like mine.  It's not a mobile, but the difference in
speed should actually be sort-of proportional to the clock frequency.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-30 Thread Phil Holmes
- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: "Werner LEMBERG" ; 
Sent: Sunday, December 30, 2018 6:46 PM
Subject: Re: GUB lilypond build fails



"Phil Holmes"  writes:

- Original Message - 
From: "Phil Holmes" 

To: "Werner LEMBERG" 
Cc: ; 
Sent: Sunday, December 30, 2018 12:29 PM
Subject: Re: GUB lilypond build fails




The problem with "NewGub" would seem to be my issue.  I've always
made and uploaded GUB in a VM with a user gub and a directory called
NewGub under that user's home directory.  I'm currently trying to
build from a user with a home directory called gubd and in a
directory called GubDir.  I do have a user called gub (it's where
the VM lives) and could create a directory called NewGub and try to
see if this works at this time.  Watch this space.



Success building from master. Thanks Werner.  Will take me a time to
sort out a build from the stable candidate, but it looks like we're on
track.

make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads...


That does not say a lot without specifying the generation.  I have in my
laptop a

model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz



core i7-2600 3.4GHz.  About 8 years old

--
Phil Holmes

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


Re: GUB lilypond build fails

2018-12-30 Thread David Kastrup
David Kastrup  writes:

> "Phil Holmes"  writes:
>
>> - Original Message - 
>> From: "Phil Holmes" 
>> To: "Werner LEMBERG" 
>> Cc: ; 
>> Sent: Sunday, December 30, 2018 12:29 PM
>> Subject: Re: GUB lilypond build fails
>>
>>
>>>
>>> The problem with "NewGub" would seem to be my issue.  I've always
>>> made and uploaded GUB in a VM with a user gub and a directory called
>>> NewGub under that user's home directory.  I'm currently trying to
>>> build from a user with a home directory called gubd and in a
>>> directory called GubDir.  I do have a user called gub (it's where
>>> the VM lives) and could create a directory called NewGub and try to
>>> see if this works at this time.  Watch this space.
>>
>>
>> Success building from master. Thanks Werner.  Will take me a time to
>> sort out a build from the stable candidate, but it looks like we're on
>> track.
>>
>> make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads...
>
> That does not say a lot without specifying the generation.  I have in my
> laptop a
>
> model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
>
> which would formally meet this specification (I think it's pretty much
> the lowest possible mobile CPU that would).  Admittedly, the laptop is
> not certified for the CPU's thermal design power and it's just since
> last year or so since I caved and upgraded, but still it's considered
> slow in comparison to today's usual horsepower.

Over the CPU bragging I forgot the most important part of this
information:

YES  Finally progress again.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-30 Thread David Kastrup
"Phil Holmes"  writes:

> - Original Message - 
> From: "Phil Holmes" 
> To: "Werner LEMBERG" 
> Cc: ; 
> Sent: Sunday, December 30, 2018 12:29 PM
> Subject: Re: GUB lilypond build fails
>
>
>>
>> The problem with "NewGub" would seem to be my issue.  I've always
>> made and uploaded GUB in a VM with a user gub and a directory called
>> NewGub under that user's home directory.  I'm currently trying to
>> build from a user with a home directory called gubd and in a
>> directory called GubDir.  I do have a user called gub (it's where
>> the VM lives) and could create a directory called NewGub and try to
>> see if this works at this time.  Watch this space.
>
>
> Success building from master. Thanks Werner.  Will take me a time to
> sort out a build from the stable candidate, but it looks like we're on
> track.
>
> make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads...

That does not say a lot without specifying the generation.  I have in my
laptop a

model name  : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz

which would formally meet this specification (I think it's pretty much
the lowest possible mobile CPU that would).  Admittedly, the laptop is
not certified for the CPU's thermal design power and it's just since
last year or so since I caved and upgraded, but still it's considered
slow in comparison to today's usual horsepower.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-30 Thread Phil Holmes
- Original Message - 
From: "Phil Holmes" 

To: "Werner LEMBERG" 
Cc: ; 
Sent: Sunday, December 30, 2018 12:29 PM
Subject: Re: GUB lilypond build fails




The problem with "NewGub" would seem to be my issue.  I've always made and 
uploaded GUB in a VM with a user gub and a directory called NewGub under 
that user's home directory.  I'm currently trying to build from a user 
with a home directory called gubd and in a directory called GubDir.  I do 
have a user called gub (it's where the VM lives) and could create a 
directory called NewGub and try to see if this works at this time.  Watch 
this space.



Success building from master. Thanks Werner.  Will take me a time to sort 
out a build from the stable candidate, but it looks like we're on track.


make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads...

--
Phil Holmes 



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


Re: GUB lilypond build fails

2018-12-30 Thread David Kastrup
"Phil Holmes"  writes:

> The problem with "NewGub" would seem to be my issue.  I've always made
> and uploaded GUB in a VM with a user gub and a directory called NewGub
> under that user's home directory.  I'm currently trying to build from
> a user with a home directory called gubd and in a directory called
> GubDir.  I do have a user called gub (it's where the VM lives) and
> could create a directory called NewGub and try to see if this works at
> this time.  Watch this space.

Just as a strategy for would-be fixers: it is not really necessary to
replace everything with relative paths: one can instead use an
environment variable like $GUBHOME or whatever as an absolute path
component.  I think there are already environment variables described
that need to be set for development/release work.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-30 Thread Phil Holmes
- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; 
Sent: Saturday, December 29, 2018 8:42 PM
Subject: Re: GUB lilypond build fails



It now fails with a different file not found, but essentially still
the same: [...]


OK.


If I try to locate the file we get: [...]


Are these files displayable?  You could try

 gv -nosafedir -nosafer foo.eps


A curious other problem which I'd not remarked on before is that a
little higher in the output I get:

Operand stack:
(/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf) 
(r)

[...]
Last OS error: No such file or directory


Does this file exist?


When I was building from git master (just a lily build, not GUB) I
had the same error until I nuked the build directory and started
from scratch.


I haven't dived into doing partial builds at all...

Right now I'm working on improving fontconfig support to not use fonts
outside of gub.  After this step I'm going to write a script to
convert the absolute file paths in the `test-output' tarball to
relative paths so that you don't need a `NewGub' user for a complete
build.



The problem with "NewGub" would seem to be my issue.  I've always made and 
uploaded GUB in a VM with a user gub and a directory called NewGub under 
that user's home directory.  I'm currently trying to build from a user with 
a home directory called gubd and in a directory called GubDir.  I do have a 
user called gub (it's where the VM lives) and could create a directory 
called NewGub and try to see if this works at this time.  Watch this space.


--
Phil Holmes 



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


Re: GUB lilypond build fails

2018-12-29 Thread Werner LEMBERG
> It now fails with a different file not found, but essentially still
> the same: [...]

OK.

> If I try to locate the file we get: [...]

Are these files displayable?  You could try

  gv -nosafedir -nosafer foo.eps

> A curious other problem which I'd not remarked on before is that a
> little higher in the output I get:
> 
> Operand stack:
> (/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf)
>  (r)
> [...]
> Last OS error: No such file or directory

Does this file exist?

> When I was building from git master (just a lily build, not GUB) I
> had the same error until I nuked the build directory and started
> from scratch.

I haven't dived into doing partial builds at all...

Right now I'm working on improving fontconfig support to not use fonts
outside of gub.  After this step I'm going to write a script to
convert the absolute file paths in the `test-output' tarball to
relative paths so that you don't need a `NewGub' user for a complete
build.


Werner


PS: Thanks for merging the pull request.

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


Re: GUB lilypond build fails

2018-12-29 Thread Phil Holmes
- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; 
Sent: Monday, December 24, 2018 9:39 PM
Subject: Re: GUB lilypond build fails





It may be of note that an earlier (i.e. 6 months' earlier)
successful run doesn't have the "invoking GS" line in its output.


What does

 locate merge-rests-engraver

say?  Are files containing this name actually present for the old
version?  And what about newer version?  Maybe a log file was created
that contains more information?


   Werner


It now failes with a different file not found, but essentially still the 
same:


invoking 
gs -sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -slilypond-datadir=v2.19.64-1/share/lilypond/current 
-r101 -dAutoRotatePages=/None -dPrinted=false -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/rest-positioning.png 
-dNOSAFER -dEPSCrop -q -dNOPAUSE v2.19.64-1/rest-positioning.eps -c quit

Traceback (most recent call last):
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/scripts/build/output-distance.py", 
line 1358, in ?

main ()

If I try to locate the file we get:

locate rest-positioning.eps
/home/gubd/GubDir/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/out-test/dynamics-rest-positioning.eps
/home/gubd/GubDir/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/out-test/rest-positioning.eps
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1/dynamics-rest-positioning.eps
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1/rest-positioning.eps
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/dynamics-rest-positioning.eps
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/rest-positioning.eps

A curious other problem which I'd not remarked on before is that a little 
higher in the output I get:


Operand stack:
(/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf) 
(r)

Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 
%stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 
%stopped_push 1983 1 3 %oparray_pop 1982 1 3 %oparray_pop --nostringval--  
1966 1 3 %oparray_pop 1852 1 3 %oparray_pop --nostringval-- %errorexec_pop 
.runexec2 --nostringval-- --nostringval-- --nostringval-- 2 
%stopped_push --nostringval--

Dictionary stack:
--dict:1213/1684(ro)(G)-- --dict:0/20(G)-- --dict:82/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 518
GPL Ghostscript 9.21: Unrecoverable error, exit code 1

When I was building from git master (just a lily build, not GUB) I had the 
same error until I nuked the build directory and started from scratch.  Hmm.


--
Phil Holmes 



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


Re: GUB lilypond build fails

2018-12-24 Thread Werner LEMBERG


> It may be of note that an earlier (i.e. 6 months' earlier)
> successful run doesn't have the "invoking GS" line in its output.

What does

  locate merge-rests-engraver

say?  Are files containing this name actually present for the old
version?  And what about newer version?  Maybe a log file was created
that contains more information?


Werner

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


Re: GUB lilypond build fails

2018-12-24 Thread Werner LEMBERG


> Now done and I get this:
> 
> Error: /undefinedfilename in (v2.19.64-1/merge-rests-engraver.eps)
>
> [...]
> 
> Which is true.  The file doesn't exist.  It should have come from
> the test-output-distance.py, I think, but have no clue as to why
> it's not there.

How many processes do run in parallel on your system?  Maybe
lilypond's makefile setup is buggy (i.e., some missing dependencies),
causing the use of `merge-rests-engraver.eps' before it is actually
generated.

Can you try to reduce the parallel jobs?


Werner

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


Re: GUB lilypond build fails

2018-12-24 Thread Phil Holmes
- Original Message - 
From: "Phil Holmes" 

To: "Werner LEMBERG" 
Cc: ; 
Sent: Monday, December 24, 2018 3:17 PM
Subject: Re: GUB lilypond build fails


- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; 
Sent: Monday, December 24, 2018 1:11 PM
Subject: Re: GUB lilypond build fails





This command seems to fail.  Can you run it manually (with proper
values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
output?  Information about the environment variables should be
available in `lilypond-test.log'.


Any idea of what would be the proper values for those 3 environment
variables?


As mentioned above!  A very long line in `lilypond-test.log' shows the
values.  Looking into my

 /home/wl/git/gub/target/linux-64/log/lilypond-test.log

file I see

 +cd 
/home/wl/git/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master 
\

 && ulimit -m 524288 \
 && ulimit -d 524288 \
 && ulimit -v 2097152 \
 && 
LILYPOND_EXTERNAL_BINARY=/home/wl/git/gub/target/linux-64/root/usr/bin/lilypond 
\

PATH=\
/home/wl/git/gub/target/tools/root/usr/bin\
:/home/wl/git/gub/target/linux-64/root/usr/bin\
:$PATH MALLOC_CHECK_=2 \
LD_LIBRARY_PATH=\
/home/wl/git/gub/target/tools/root/usr/lib\
:/home/wl/git/gub/target/linux-64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} 
\

GS_FONTPATH=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/fonts\
:/home/wl/git/gub/target/linux-64/root/usr/share/gs/fonts \
GS_LIB=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource/Init\
:/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource 
\


FONTCONFIG_FILE=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts/fonts.conf 
\

FONTCONFIG_PATH=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts \
make -j4 \
 CPU_COUNT=2 \
 MISSING_OPTIONAL=dblatex \
 test

Put the environment variables after the last `&&' into a shell script
and execute the gs command in the right directory (given as the first
`cd' command).


  Werner



I'll try a build of current master.




Same problem for me.

--
Phil Holmes 



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


Re: GUB lilypond build fails

2018-12-24 Thread Phil Holmes




--
Phil Holmes


- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; 
Sent: Monday, December 24, 2018 1:11 PM
Subject: Re: GUB lilypond build fails





This command seems to fail.  Can you run it manually (with proper
values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
output?  Information about the environment variables should be
available in `lilypond-test.log'.


Any idea of what would be the proper values for those 3 environment
variables?


As mentioned above!  A very long line in `lilypond-test.log' shows the
values.  Looking into my

 /home/wl/git/gub/target/linux-64/log/lilypond-test.log

file I see

 +cd 
/home/wl/git/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master 
\

 && ulimit -m 524288 \
 && ulimit -d 524288 \
 && ulimit -v 2097152 \
 && 
LILYPOND_EXTERNAL_BINARY=/home/wl/git/gub/target/linux-64/root/usr/bin/lilypond 
\

PATH=\
/home/wl/git/gub/target/tools/root/usr/bin\
:/home/wl/git/gub/target/linux-64/root/usr/bin\
:$PATH MALLOC_CHECK_=2 \
LD_LIBRARY_PATH=\
/home/wl/git/gub/target/tools/root/usr/lib\
:/home/wl/git/gub/target/linux-64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} 
\

GS_FONTPATH=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/fonts\
:/home/wl/git/gub/target/linux-64/root/usr/share/gs/fonts \
GS_LIB=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource/Init\
:/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource 
\


FONTCONFIG_FILE=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts/fonts.conf 
\

FONTCONFIG_PATH=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts \
make -j4 \
 CPU_COUNT=2 \
 MISSING_OPTIONAL=dblatex \
 test

Put the environment variables after the last `&&' into a shell script
and execute the gs command in the right directory (given as the first
`cd' command).


  Werner



It may be of note that an earlier (i.e. 6 months' earlier) successful run 
doesn't have the "invoking GS" line in its output.  I'll paste the early 
good run below and the later bad run below that.  I do have one thought now, 
though.  I'm running against release/unstable.  That's probably not been 
updated with some fixes,  I'll try a build of current master.


Good build:

1 below threshold
3755 unchanged
mkdir /home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1
mkdir 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1
v2.19.81-1/parallelmusic-partial.profile -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/parallelmusic-partial.profile
mkdir 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1
v2.19.82-1/parallelmusic-partial.profile -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/parallelmusic-partial.profile
v2.19.81-1/parallelmusic-partial.log -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/parallelmusic-partial.log
v2.19.82-1/parallelmusic-partial.log -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/parallelmusic-partial.log
v2.19.81-1/make-relative.log -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/make-relative.log
v2.19.82-1/make-relative.log -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/make-relative.log
v2.19.81-1/tree.gittxt -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/tree.gittxt
v2.19.82-1/tree.gittxt -> 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/tree.gittxt
writing 
"/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/index.txt"
tar --strip-component=3 -C 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack/v2.19.81-1 -xjf 
regtests/lilypond-2.19.81-1.test-output.tar.bz2
tar --strip-component=3 -C 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack/v2.19.82-1 -xjf 
uploads/lilypond-2.19.82-1.test-output.tar.bz2
cd /home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack && python 
/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/scripts/build/output-distance.py 
--create-images --output-dir 
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1 --local-datadir 
v2.19.81-1 v2.19.82-1

rm -rf /home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack
make[3]: Leaving directory `/home/gub/NewGub/gub'
make[2]: Leaving directory `/home/gub/NewGub/gub'
 test rule



Failed build:

1251 below threshold
1161 unchanged
mkdir /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1
mkdir 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.21.0-1
mkdir 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1
v2.19.64-1/merge-rests-engraver.ly -&g

Re: GUB lilypond build fails

2018-12-24 Thread Phil Holmes




--
Phil Holmes


- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; 
Sent: Monday, December 24, 2018 1:11 PM
Subject: Re: GUB lilypond build fails





This command seems to fail.  Can you run it manually (with proper
values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
output?  Information about the environment variables should be
available in `lilypond-test.log'.


Any idea of what would be the proper values for those 3 environment
variables?


As mentioned above!  A very long line in `lilypond-test.log' shows the
values.  Looking into my

 /home/wl/git/gub/target/linux-64/log/lilypond-test.log


Sorry.

Now done and I get this:

gubd@ubuntu12:~$ ./gs_test.sh
Error: /undefinedfilename in (v2.19.64-1/merge-rests-engraver.eps)
Operand stack:

Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 
%stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 
%stopped_push

Dictionary stack:
--dict:1212/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.21: Unrecoverable error, exit code 1

Which is true.  The file doesn't exist.  It should have come from the 
test-output-distance.py, I think, but have no clue as to why it's not there.


I'd appreciate anyone's further insight as to what might have happened.  I 
might just try running GUB again in case it was a glitch.


--
Phil Holmes 



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


Re: GUB lilypond build fails

2018-12-24 Thread Werner LEMBERG


>> This command seems to fail.  Can you run it manually (with proper
>> values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
>> output?  Information about the environment variables should be
>> available in `lilypond-test.log'.
> 
> Any idea of what would be the proper values for those 3 environment
> variables?

As mentioned above!  A very long line in `lilypond-test.log' shows the
values.  Looking into my

  /home/wl/git/gub/target/linux-64/log/lilypond-test.log

file I see

  +cd 
/home/wl/git/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master
 \
  && ulimit -m 524288 \
  && ulimit -d 524288 \
  && ulimit -v 2097152 \
  && 
LILYPOND_EXTERNAL_BINARY=/home/wl/git/gub/target/linux-64/root/usr/bin/lilypond 
\
 PATH=\
/home/wl/git/gub/target/tools/root/usr/bin\
:/home/wl/git/gub/target/linux-64/root/usr/bin\
:$PATH MALLOC_CHECK_=2 \
 LD_LIBRARY_PATH=\
/home/wl/git/gub/target/tools/root/usr/lib\
:/home/wl/git/gub/target/linux-64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
 \
 GS_FONTPATH=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/fonts\
:/home/wl/git/gub/target/linux-64/root/usr/share/gs/fonts \
 GS_LIB=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource/Init\
:/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource \
 
FONTCONFIG_FILE=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts/fonts.conf \
 FONTCONFIG_PATH=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts \
 make -j4 \
  CPU_COUNT=2 \
  MISSING_OPTIONAL=dblatex \
  test

Put the environment variables after the last `&&' into a shell script
and execute the gs command in the right directory (given as the first
`cd' command).


   Werner

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


Re: GUB lilypond build fails

2018-12-24 Thread Phil Holmes
- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; ; 
Sent: Sunday, December 23, 2018 11:19 PM
Subject: Re: GUB lilypond build fails





Almost completed a GUB build today, building against
release/unstable.  Unfortunately it eventually failed with the errors
below.  Can anyone suggest what ids going wrong?

invoking gs -sDEVICE=png16m \
-dGraphicsAlphaBits=4 \
-dTextAlphaBits=4 \
-slilypond-datadir=v2.19.64-1/share/lilypond/current \
-r101 \
-dAutoRotatePages=/None \
-sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.png 
\

-dNOSAFER \
-dEPSCrop \
-q \
-dNOPAUSE \
v2.19.64-1/merge-rests-engraver.eps
-c quit


This command seems to fail.  Can you run it manually (with proper
values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
output?  Information about the environment variables should be
available in `lilypond-test.log'.


   Werner



Any idea of what would be the proper values for those 3 environment 
variables?


--
Phil Holmes 



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


Re: GUB lilypond build fails

2018-12-23 Thread Werner LEMBERG


> Almost completed a GUB build today, building against
> release/unstable.  Unfortunately it eventually failed with the errors
> below.  Can anyone suggest what ids going wrong?
> 
> invoking gs -sDEVICE=png16m \
> -dGraphicsAlphaBits=4 \
> -dTextAlphaBits=4 \
> -slilypond-datadir=v2.19.64-1/share/lilypond/current \
> -r101 \
> -dAutoRotatePages=/None \
> 
> -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.png
>  \
> -dNOSAFER \
> -dEPSCrop \
> -q \
> -dNOPAUSE \
> v2.19.64-1/merge-rests-engraver.eps
> -c quit

This command seems to fail.  Can you run it manually (with proper
values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
output?  Information about the environment variables should be
available in `lilypond-test.log'.


Werner

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


Re: GUB lilypond build fails

2018-12-23 Thread Phil Holmes
Almost completed a GUB build today, building against release/unstable. 
Unfortunately it eventually failed with the errors below.  Can anyone 
suggest what ids going wrong?


mkdir /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1
mkdir 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.21.0-1
mkdir 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1
v2.19.64-1/merge-rests-engraver.ly -> 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.ly
v2.21.0-1/merge-rests-engraver.ly -> 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.21.0-1/merge-rests-engraver.ly
invoking 
gs -sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -slilypond-datadir=v2.19.64-1/share/lilypond/current 
-r101 -dAutoRotatePages=/None -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.png 
-dNOSAFER -dEPSCrop -q -dNOPAUSE v2.19.64-1/merge-rests-engraver.eps -c 
quit

Traceback (most recent call last):
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", 
line 1349, in ?

main ()
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", 
line 1346, in main

compare_tree_pairs (zip (args[0::2], args[1::2]), out, options.threshold)
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", 
line 1061, in compare_tree_pairs

data.create_html_result_page (dest_dir, threshold)
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", 
line 1043, in create_html_result_page

link.link_files_for_html (dest_dir)
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", 
line 660, in link_files_for_html

to_compare = self.create_images (dest_dir)
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", 
line 650, in create_images

system (cmd)
File 
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", 
line 1091, in system

assert stat == 0
AssertionError
tar --strip-component=3 -C 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1 -xjf 
regtests/lilypond-2.19.64-1.test-output.tar.bz2
tar --strip-component=3 -C 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1 -xjf 
uploads/lilypond-2.21.0-1.test-output.tar.bz2
cd /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack && python 
/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py 
--create-images --output-dir 
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1 --local-datadir 
v2.19.64-1 v2.21.0-1

Traceback (most recent call last):
File "test-lily/rsync-test.py", line 204, in ?
main ()
File "test-lily/rsync-test.py", line 198, in main
compare_test_info (options)
File "test-lily/rsync-test.py", line 169, in compare_test_info
compare_test_tarballs (options, versions_found[-3:])
File "test-lily/rsync-test.py", line 119, in compare_test_tarballs
system (cmd)
File "test-lily/rsync-test.py", line 77, in system
raise Exception ('fail')
Exception: fail
make[3]: *** [unlocked-test-export] Error 1
make[3]: Leaving directory `/home/gubd/GubDir/gub'
make[2]: *** [cached-test-export] Error 2
make[2]: Leaving directory `/home/gubd/GubDir/gub'
make[1]: *** [test-export] Error 2
make[1]: Leaving directory `/home/gubd/GubDir/gub'
make: *** [lilypond] Error 2



--
Phil Holmes 



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


Re: GUB lilypond build fails

2018-12-17 Thread David Kastrup
Werner LEMBERG  writes:

>> So it would be really _urgent_ to get GUB advanced to a recent
>> version of Python 2 in all supported platforms
>
> Yes.
>
>> (and I think we can delist the PPC platform support by now):
>
> What's exactly the reason for this?

Considerable resources in compilation and maintenance time without an
obvious user?

>> But at least PPC seems reasonably safe to retire, and possibly
>> FreeBSD if it helps.
>
> AFAIK, it doesn't help since the requirements are the same.

Whoever does the human GUB work (in this case moving Python to newer
versions) gets to decide this I guess.  Whoever does it is in my book
free to decide to drop it after looking at it as thoroughly or casually
as they consider fit.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-17 Thread Werner LEMBERG
> So it would be really _urgent_ to get GUB advanced to a recent
> version of Python 2 in all supported platforms

Yes.

> (and I think we can delist the PPC platform support by now):

What's exactly the reason for this?

> But at least PPC seems reasonably safe to retire, and possibly
> FreeBSD if it helps.

AFAIK, it doesn't help since the requirements are the same.


Werner

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


Re: GUB lilypond build fails

2018-12-17 Thread David Kastrup


Andrew Bernard  writes:

> Hi All,
>
> I am new to lilypond dev. work. My intention may be naive, but I am wanting
> to do the work to uplift gub and lilypond to python 3. Am I premature, or
> foolish, or misguided? I did have some encouraging email about this
> previously, but I just wanted to check before I dive in and spend large
> amounts of time, especially re GUB.

I have yesterday asked Masamichi-san to take a look at our current GUB
problems but it would appear that Werner found and fixed the source of
the current roadblock.  Now it sounded like Masamichi-san was currently
rather short of time for this, so it would make sense that now, since
the immediate problem appears to be solved, you take a look at this
instead with a perspective of a Python 3 migration eventually.

So I did some "git blame" searching and it would appear that the
Python 2.5 "ism" was introduced with commit

commit 7b07440da921d979ab492fd284b6198152a8020c
Author: Alexander Myltsev 
AuthorDate: Thu Jun 2 11:19:07 2016 +0300
Commit: James Lowe 
CommitDate: Sat Jun 16 10:59:08 2018 +0100

musicxml2ly: handle hidden time signatures.

Now I don't really feel that we can indeed pass any blame for not being
aware of having to use syntax for an ancient rather than an antique
version of Python.  And we apparently don't have the manpower in place
to figure out what went wrong: this put our release process to a halt
for almost half a year.

So it would be really _urgent_ to get GUB advanced to a recent version
of Python 2 in all supported platforms (and I think we can delist the
PPC platform support by now): the current Python 2 requirement is
obvious, the Python 2.4 requirement not.

Moving to a current Python 2 version should be doable without changing
the LilyPond source code: that's a pure GUB job, though one that might
be bothersome on some platforms.  Decommissioning the PPC platforms
would likely make this easier, and I don't think we really have active
users there.  Masamichi-san also suggested stopping FreeBSD support (I
don't know if there is much of an indication the binary installation
from us is used rather than compiling themselves, and supposedly they
can run Linux binaries though the runtime environment may be
troublesome) and Windows 32-bit support.  I am not sure whether there
aren't people running 32-bit Windows binaries in VMs though.

But at least PPC seems reasonably safe to retire, and possibly FreeBSD
if it helps.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-16 Thread Andrew Bernard
Hi Carl,

I'm on the case. This is the sort of work I can do. I have never been able
to get into the groove of lilypond internals for some reason, but this type
of system building tool is right up my alley.

Andrew


On Mon, 17 Dec 2018 at 14:53, Carl Sorensen  wrote:

>
> GUB provides us a pretty wonderful functionality -- it builds for Linux,
> Windows, and OSX, so we can provide pre-built binaries for all of those
> platforms.
>
> I think that you need to investigate and make your own decision.  Spend a
> bit of time trying to get to understand GUB.  Try making the changes you
> want to make.  See how it works.  See if you can wrap your arms around it.
> If you can become an expert in GUB, you'll be an invaluable asset to the
> Lilypond development team.  Personally, I'd love to have you do that!
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: GUB lilypond build fails

2018-12-16 Thread David Kastrup
Carl Sorensen  writes:

> On 12/16/18, 6:42 PM, "lilypond-devel on behalf of Andrew Bernard"
>  andrew.bern...@gmail.com> wrote:
>
> Hi All,
> 
> I am new to lilypond dev. work. My intention may be naive, but I am 
> wanting
> to do the work to uplift gub and lilypond to python 3. Am I premature, or
> foolish, or misguided? I did have some encouraging email about this
> previously, but I just wanted to check before I dive in and spend large
> amounts of time, especially re GUB.
>
>
> I'm quite certain you're not premature.
>
> I don't know if you're foolish or misguided.
>
> GUB is a lot old, and a little bit (or maybe more) fragile.  It's
> primary developer (Jan) has decided he doesn't want to work more on
> it.  He'd rather pursue a different method of doing the
> cross-compilation.

Nix will not build Windows binaries, so it's not like his current
pursuits will lead to a replacement of what GUB does for us.

We don't really have any workable alternative on the horizon.  But I do
think we can retire at least the PPC platforms.  And I don't think the
FreeBSD compilations are used a lot either.

> I think that you need to investigate and make your own decision.
> Spend a bit of time trying to get to understand GUB.  Try making the
> changes you want to make.  See how it works.  See if you can wrap your
> arms around it.  If you can become an expert in GUB, you'll be an
> invaluable asset to the Lilypond development team.  Personally, I'd
> love to have you do that!

A Python 3 migration would be useful but of course requires some GUB
lifting.  It definitely would be a sizable amount of work.

-- 
David Kastrup

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


Re: GUB lilypond build fails

2018-12-16 Thread Carl Sorensen


On 12/16/18, 6:42 PM, "lilypond-devel on behalf of Andrew Bernard" 
 wrote:

Hi All,

I am new to lilypond dev. work. My intention may be naive, but I am wanting
to do the work to uplift gub and lilypond to python 3. Am I premature, or
foolish, or misguided? I did have some encouraging email about this
previously, but I just wanted to check before I dive in and spend large
amounts of time, especially re GUB.


I'm quite certain you're not premature.

I don't know if you're foolish or misguided.

GUB is a lot old, and a little bit (or maybe more) fragile.  It's primary 
developer (Jan) has decided he doesn't want to work more on it.  He'd rather 
pursue a different method of doing the cross-compilation.

GUB provides us a pretty wonderful functionality -- it builds for Linux, 
Windows, and OSX, so we can provide pre-built binaries for all of those 
platforms.

I think that you need to investigate and make your own decision.  Spend a bit 
of time trying to get to understand GUB.  Try making the changes you want to 
make.  See how it works.  See if you can wrap your arms around it.  If you can 
become an expert in GUB, you'll be an invaluable asset to the Lilypond 
development team.  Personally, I'd love to have you do that!

Thanks,

Carl

 

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


Re: GUB lilypond build fails

2018-12-16 Thread Andrew Bernard
Hi All,

I am new to lilypond dev. work. My intention may be naive, but I am wanting
to do the work to uplift gub and lilypond to python 3. Am I premature, or
foolish, or misguided? I did have some encouraging email about this
previously, but I just wanted to check before I dive in and spend large
amounts of time, especially re GUB.

Andrew


On Mon, 17 Dec 2018 at 12:16, Carl Sorensen  wrote:

>
>
> On 12/16/18, 4:38 PM, "lilypond-devel on behalf of Werner LEMBERG"
> 
> wrote:
>
>
> >I think you have the same issue me and others had.  You don't see
> >it in the tail below, but if you open the lilypond.log file
> >you'll see a python command failing to generate a file because
> >GUB python is 2.4 while lilypond python code uses if statements.
> >It's discussed in one of the pull requests on GitHub.
>
> I took to liberty to `hotfix' this issue in the lilypond git
> repository: There was a single place in `musicexp.py' that used 2.5
> syntax, which I've just changed back to 2.4 syntax in `staging'.
>
> Thank you, Werner!  That is an excellent solution.
>
> We will still want to look into a long-term fix in the build/distribution
> system.  But getting it to work right now is really important.
>
> Thanks,
>
>
> Carl
>
>
> ___
> 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: GUB lilypond build fails

2018-12-16 Thread Carl Sorensen


On 12/16/18, 4:38 PM, "lilypond-devel on behalf of Werner LEMBERG" 
 
wrote:


>I think you have the same issue me and others had.  You don't see
>it in the tail below, but if you open the lilypond.log file
>you'll see a python command failing to generate a file because
>GUB python is 2.4 while lilypond python code uses if statements.
>It's discussed in one of the pull requests on GitHub.

I took to liberty to `hotfix' this issue in the lilypond git
repository: There was a single place in `musicexp.py' that used 2.5
syntax, which I've just changed back to 2.4 syntax in `staging'.

Thank you, Werner!  That is an excellent solution.

We will still want to look into a long-term fix in the build/distribution 
system.  But getting it to work right now is really important.

Thanks,


Carl


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


Re: GUB lilypond build fails

2018-12-16 Thread Werner LEMBERG

> lilypond should now build with gub as soon as this commit goes to
> `master'.

To be more precise: I can build lilypond with gub on my openSuSE Leap
42.3 GNU/Linux box.[*]

I use the attached patches for gub (relative to HEAD), which are based
on

  https://github.com/gperciva/gub/pull/7

plus some other changes that I'm going to submit as soon as my gub
build completes.


Werner


[*] The nasty `ar' bug I've reported some time ago is still present
but I can circumvent the issue.  IMHO this is nothing gub should
take care of.
diff --git a/arbora.make b/arbora.make
index 1754d77d..8b9250ba 100644
--- a/arbora.make
+++ b/arbora.make
@@ -45,10 +45,10 @@ arbora-installers:
 	$(foreach p, $(PLATFORMS), $(call INVOKE_INSTALLER_BUILDER,$(p)) $(INSTALL_PACKAGE) &&) true #
 
 nsis:
-	bin/gub tools::nsis
+	$(GUB) tools::nsis
 
 update-versions:
-	python gub/versiondb.py --no-sources --version-db=versiondb/arbora.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/arbora
+	$(PYTHON) gub/versiondb.py --no-sources --version-db=versiondb/arbora.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/arbora
 
 print-success:
 	@echo "success!!"
diff --git a/bin/gib b/bin/gib
index 0a7ccf39..91d98b64 100755
--- a/bin/gib
+++ b/bin/gib
@@ -102,6 +102,11 @@ Examples:
 
 (options, args) = p.parse_args ()
 
+if not args:
+gub_log.error ('error: nothing to do\n')
+p.print_help ()
+sys.exit (2)
+
 return (options, args)
 
 def check_installer (installer, options, args):
diff --git a/bin/gub b/bin/gub
index dd4b3763..261e7f90 100755
--- a/bin/gub
+++ b/bin/gub
@@ -280,7 +280,7 @@ def environment_sanity (settings):
 if os.path.exists (environment_file):
 environment = dict (pickle.loads (open (environment_file, 'rb').read ()))
 # expand any ~ in the PATH
-os.environ['PATH'] = ":".join( map( lambda(x):os.path.expanduser(x),
+os.environ['PATH'] = ":".join( map( os.path.expanduser,
 os.environ['PATH'].split(':')))
 differ = []
 for key in list (misc.uniq (sorted (environment.keys ()
diff --git a/denemo.make b/denemo.make
index 60508814..b1343988 100644
--- a/denemo.make
+++ b/denemo.make
@@ -52,10 +52,10 @@ denemo-installers:
 	$(foreach p, $(PLATFORMS), $(call INVOKE_INSTALLER_BUILDER,$(p)) $(INSTALL_PACKAGE) &&) true #
 
 nsis:
-	bin/gub tools::nsis
+	$(GUB) tools::nsis
 
 update-versions:
-	python gub/versiondb.py --no-sources --version-db=versiondb/denemo.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/denemo
+	$(PYTHON) gub/versiondb.py --no-sources --version-db=versiondb/denemo.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/denemo
 
 print-success:
 	@echo "success!!"
diff --git a/gub/dependency.py b/gub/dependency.py
index 6518102e..3220d8ed 100644
--- a/gub/dependency.py
+++ b/gub/dependency.py
@@ -35,7 +35,7 @@ def get_build_from_file (platform, file_name, name):
 and (not cls or issubclass (cls, target.AutoBuild))):
 cls = misc.most_significant_in_dict (module.__dict__, class_name.replace ('tools32', 'tools'), '__')
 if ((platform == 'tools' or platform == 'tools32')
-and (issubclass (cls, target.AutoBuild)
+and (not cls or issubclass (cls, target.AutoBuild)
  and not issubclass (cls, tools.AutoBuild)
  and not issubclass (cls, tools32.AutoBuild))):
 cls = None
diff --git a/gub/specs/autoconf.py b/gub/specs/autoconf.py
index 6435d892..0c7b200f 100644
--- a/gub/specs/autoconf.py
+++ b/gub/specs/autoconf.py
@@ -7,3 +7,6 @@ class Autoconf__tools (tools.AutoBuild):
 'm4',
 'perl',
 ]
+# prevent execution of Emacs to build .elc files
+configure_variables = (tools.AutoBuild.configure_variables
+   + ' EMACS=false')
diff --git a/gub/specs/darwin/cross/gcc.py b/gub/specs/darwin/cross/gcc.py
index a0c349b0..bca7923e 100644
--- a/gub/specs/darwin/cross/gcc.py
+++ b/gub/specs/darwin/cross/gcc.py
@@ -3,6 +3,7 @@ import os
 from gub.specs.cross import gcc as cross_gcc
 from gub import loggedos
 from gub import cross
+from gub import misc
 
 class Gcc__darwin (cross_gcc.Gcc):
 dependencies = ['tools::gmp', 'tools::mpfr', 'tools::mpc', 'odcctools']
@@ -13,6 +14,10 @@ class Gcc__darwin (cross_gcc.Gcc):
 configure_flags = (cross_gcc.Gcc.configure_flags
+ ' --disable-libcilkrts'
 )
+configure_variables = (cross_gcc.Gcc.configure_variables
+   + misc.join_lines ('''
+MAKEINFO=no
+'''))
 def languages (self):
 # objective-c is used for quartz's Carbon/Carbon.h in pango, gtk+
 return cross_gcc.Gcc.languages (self) + ['objc', 'obj-c++']
diff --git a/gub/specs/freebsd/cross/gcc.py b/gub/specs/freebsd/cross/gcc.py
index 663a8bd3..4b25d366 100644
--- 

Re: GUB lilypond build fails

2018-12-16 Thread Werner LEMBERG


>I think you have the same issue me and others had.  You don't see
>it in the tail below, but if you open the lilypond.log file
>you'll see a python command failing to generate a file because
>GUB python is 2.4 while lilypond python code uses if statements.
>It's discussed in one of the pull requests on GitHub.

I took to liberty to `hotfix' this issue in the lilypond git
repository: There was a single place in `musicexp.py' that used 2.5
syntax, which I've just changed back to 2.4 syntax in `staging'.

lilypond should now build with gub as soon as this commit goes to
`master'.


Werner

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


Re: GUB lilypond build fails

2018-12-16 Thread Federico Bruni
   Hi Andrew
   I think you have the same issue me and others had. You don't see it in
   the tail below, but if you open the lilypond.log file you'll see a
   python command failing to generate a file because GUB python is 2.4
   while lilypond python code uses if statements.
   It's discussed in one of the pull requests on GitHub.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


GUB lilypond build fails

2018-12-16 Thread Andrew Bernard
I am setup with lilydev 0.3, the latest release. I have installed gub from
github, current master. Gub bootstrap runs to completion with no errors.
Attempting to make lilypond, it fails as follows:

$ bin/gub lilypond

building package: linux-64::lilypond
 *** Stage: download (lilypond, linux-64)
 *** Stage: untar (lilypond, linux-64)
 *** Stage: patch (lilypond, linux-64)
 *** Stage: autoupdate (lilypond, linux-64)
 *** Stage: configure (lilypond, linux-64)
 *** Stage: compile (lilypond, linux-64)
 *** Stage: install (lilypond, linux-64)
Command barfed: cd
/u01/work/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master
&& make  TARGET_PYTHON=/usr/bin/python
DESTDIR=/u01/work/gub/target/linux-64/install/lilypond-2.21.0-root install

Tail of target/linux-64/log/lilypond.log 
make[1]: *** [local-install-outfiles] Error 1
make[1]: Leaving directory
`/u01/work/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master/python'
make: *** [install] Error 2
Command barfed: cd
/u01/work/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master
&& make  TARGET_PYTHON=/usr/bin/python
DESTDIR=/u01/work/gub/target/linux-64/install/lilypond-2.21.0-root install
 Tail of target/linux-64/log/lilypond.log

*** Failed target: linux-64::lilypond

What step have I missed?

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