Re: Please test gub

2019-01-29 Thread Urs Liska


Am 29.01.19 um 14:58 schrieb Knut Petersen:

On 29.01.19 14:30, Urs Liska wrote:


Looks like 64-bit Ubuntu, like my main machine. With an earlier
gub-version I had similiar problem, because of missing 32-bit
libraries.
I got further after installing:
lib32ncurses5
lib32z1


I suspect that

apt-get install libc6-dev-i386

fixes the problem on ubuntu 18.04



I installed the two packages Harm mentioned, and now it seems to be 
running pretty successfully. I'll report back when it finishes


Neither libn32curses5 nor lib32z1 are installed in my ubuntu 18.04 
chroot environment that succeeds to finish gub runs, so these libs 
seem to be not required. Probably they pull in something we need. I 
verified that  removing libc6-dev-i386 and the libs it pulls in breaks 
building. But the question which libs are required can probably best 
be answered with the help of strace.


Knut


After installing these two packages the build on my server seems to have 
succeeded, so I did some more tests:


a) remove the two packages and rm -rf target/darwin-ppc
=> The build failed again at the same position with darwin-ppc::odcctools

b) install libc6-dev-i386 and rm -rf target/darwin-ppc
=> The build completed in 25 minutes, obviously rebuilding that target 
successfully.


HTH for identifying the dependencies.

Urs

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


Re: Please test gub

2019-01-29 Thread Werner LEMBERG


> The resulting installers all have SHA256 checksums different than the
> ones from Urs Liska's Nextcloud share.

Are you sure that the build refers to exactly the same lilypond git
commit as Urs's installers?  HEAD is continuously updated...

> I don't know what's expected with that.

It would be great to ensure identical SHA256 checksums, but right now
I consider this as not extremely urgent.  BTW, getting identical
checksums *for the doc bundle* is probably only possible if you have a
gub installation containing a TeXLive package also.


Werner

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


Re: Please test gub

2019-01-29 Thread Karlin High

On 1/29/2019 7:43 AM, Karlin High wrote:


Off and running again for now


Near as I can tell, the build succeeded. System specs given in an 
earlier post. I forgot to use the "time" command, so I don't know 
exactly how long it took. Going by logs, I'd say just under 10 hours. 
Next time, I'll let the VM have more cores.


The resulting installers all have SHA256 checksums different than the 
ones from Urs Liska's Nextcloud share. I don't know what's expected with 
that.


The internet service here has unlimited 30 Mbps upload. That's if anyone 
wants build results or even the entire VirtualBox VM.

--
Karlin High
Missouri, USA

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


Re: Please test gub

2019-01-29 Thread Thomas Morley
Am Mi., 30. Jan. 2019 um 01:28 Uhr schrieb John Mandereau
:
>
> Hi Harm,
> Le mardi 29 janvier 2019 à 23:47 +0100, Thomas Morley a écrit :
> > Doing
> > $ chromium-browser gub/uploads/webdoc/v2.21.0/index.html
> > None of the tested links seem to work.
> >
> > But for
> > $ chromium-browser gub/uploads/localdoc/v2.21.0/index.html
> > all links seem to work.
> >
> > No clue whether this is expected behaviour or not ...
>
> In order to test contents of gub/uploads/webdoc, you need to serve it
> with a webserver with content negotiation. This is merely FYI; I don't
> suggest spending much energy on testing this particular output (webdoc)
> of GUB; testing binaries, "localdoc", and examining regresssion tests
> comparison, with several branches (master and stable/2.20) have
> certainly a higher priority.
>
> Best
> --
> John Mandereau

Hi John,

thanks for the insight.

Cheers,
  Harm

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


Re: Please test gub

2019-01-29 Thread John Mandereau
Hi Harm,
Le mardi 29 janvier 2019 à 23:47 +0100, Thomas Morley a écrit :
> Doing
> $ chromium-browser gub/uploads/webdoc/v2.21.0/index.html
> None of the tested links seem to work.
> 
> But for
> $ chromium-browser gub/uploads/localdoc/v2.21.0/index.html
> all links seem to work.
> 
> No clue whether this is expected behaviour or not ...

In order to test contents of gub/uploads/webdoc, you need to serve it
with a webserver with content negotiation. This is merely FYI; I don't
suggest spending much energy on testing this particular output (webdoc)
of GUB; testing binaries, "localdoc", and examining regresssion tests
comparison, with several branches (master and stable/2.20) have
certainly a higher priority.

Best
-- 
John Mandereau


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


Re: Please test gub

2019-01-29 Thread Thomas Morley
Am Di., 29. Jan. 2019 um 23:08 Uhr schrieb Thomas Morley
:
>
> Am Mo., 28. Jan. 2019 um 13:53 Uhr schrieb Knut Petersen
> :
> >
> > Hi everybody!
> >
> > I created a branch in my gub repository  that contains 
> > https://github.com/gperciva plus pull requests 53-60. Therefore it is 
> > pretty easy to test if that version of gub succeeds to build current 
> > lilypond master on your machine.
> >
> > All you need to do is to execute the following commands:
> >
> > git clone https://github.com/knupero/gub.git -b DevelHead
> > cd gub
> > mkdir regtests
> > cd regtests
> > wget 
> > http://lilypond.org/downloads/binaries/test-output/lilypond-2.19.82-1.test-output.tar.bz2
> > touch ignore
> > cd ..
> > time make lilypond
> >
> > Even on a fast computer 'make lilypond' will take some hours to complete.
> >
> > If downloading of a source archive fails because of some network problem 
> > restart 'make lilypond'.
> >
> > You'll need some free disk space ... about 20 GB is a minimum.
> >
> > Please report success / fails with os / version / cpu info.
> >
> > Knut
>
> Success on Ubuntu-18.04 64-bit:
> [...]
> make[1]: Leaving directory '/home/hermann/gub'
>
> real 1101m55,592s
> user 1903m38,415s
> sys 305m38,341s
>
>
>
> $ uname -a
> Linux kasten 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC
> 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> $ cat /proc/cpuinfo
> model name : Intel(R) Pentium(R) CPU  N3510  @ 1.99GHz
>
>
>
> Some Remarks/Observations:
>
> - As said already, I had lib32ncurses5 and lib32z1 installed.
>   Afaict, libc6-dev-i386 is _not_ installed
>
> - Some excerpts of /target/linux-64/log/python.log
> *** WARNING: renaming "crypt" since importing it failed:
> build/lib.linux-x86_64-2.4/crypt.so: undefined symbol: crypt
> *** WARNING: renaming "nis" since importing it failed:
> build/lib.linux-x86_64-2.4/nis.so: undefined symbol: yp_master
> changing mode of
> //home/hermann/gub/target/linux-64/install/python-2.4.5-root/usr/lib/python2.4/lib-dynload/crypt_failed.so
> to 755
> changing mode of
> //home/hermann/gub/target/linux-64/install/python-2.4.5-root/usr/lib/python2.4/lib-dynload/nis_failed.so
> to 755
> failed python modules:crypt_failed.so, nis_failed.so
>
> - Similar in /target/tools/log/python.log
> [...]
> failed python modules:nis_failed.so

Addendum:

Doing
$ chromium-browser gub/uploads/webdoc/v2.21.0/index.html
None of the tested links seem to work.

But for
$ chromium-browser gub/uploads/localdoc/v2.21.0/index.html
all links seem to work.

No clue whether this is expected behaviour or not ...

Cheers,
  Harm

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


Re: Please test gub

2019-01-29 Thread Thomas Morley
Am Mo., 28. Jan. 2019 um 13:53 Uhr schrieb Knut Petersen
:
>
> Hi everybody!
>
> I created a branch in my gub repository  that contains 
> https://github.com/gperciva plus pull requests 53-60. Therefore it is pretty 
> easy to test if that version of gub succeeds to build current lilypond master 
> on your machine.
>
> All you need to do is to execute the following commands:
>
> git clone https://github.com/knupero/gub.git -b DevelHead
> cd gub
> mkdir regtests
> cd regtests
> wget 
> http://lilypond.org/downloads/binaries/test-output/lilypond-2.19.82-1.test-output.tar.bz2
> touch ignore
> cd ..
> time make lilypond
>
> Even on a fast computer 'make lilypond' will take some hours to complete.
>
> If downloading of a source archive fails because of some network problem 
> restart 'make lilypond'.
>
> You'll need some free disk space ... about 20 GB is a minimum.
>
> Please report success / fails with os / version / cpu info.
>
> Knut

Success on Ubuntu-18.04 64-bit:
[...]
make[1]: Leaving directory '/home/hermann/gub'

real 1101m55,592s
user 1903m38,415s
sys 305m38,341s



$ uname -a
Linux kasten 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/cpuinfo
model name : Intel(R) Pentium(R) CPU  N3510  @ 1.99GHz



Some Remarks/Observations:

- As said already, I had lib32ncurses5 and lib32z1 installed.
  Afaict, libc6-dev-i386 is _not_ installed

- Some excerpts of /target/linux-64/log/python.log
*** WARNING: renaming "crypt" since importing it failed:
build/lib.linux-x86_64-2.4/crypt.so: undefined symbol: crypt
*** WARNING: renaming "nis" since importing it failed:
build/lib.linux-x86_64-2.4/nis.so: undefined symbol: yp_master
changing mode of
//home/hermann/gub/target/linux-64/install/python-2.4.5-root/usr/lib/python2.4/lib-dynload/crypt_failed.so
to 755
changing mode of
//home/hermann/gub/target/linux-64/install/python-2.4.5-root/usr/lib/python2.4/lib-dynload/nis_failed.so
to 755
failed python modules:crypt_failed.so, nis_failed.so

- Similar in /target/tools/log/python.log
[...]
failed python modules:nis_failed.so


Great work so far, many thanks,
  Harm

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


Re: Please test new lilypond installers

2019-01-29 Thread David Wright
On Tue 29 Jan 2019 at 10:19:33 (+0100), Knut Petersen wrote:
> Hi everybody
> 
> Urs Liska provides installers for branch master of lilypond, generated by an 
> updated version of our build system GUB:
> 
>https://cloud.ursliska.de/s/QPINwLqJNeVslCu
> 
> There you'll find
> 
>lilypond-2.21.0-1.darwin-ppc.tar.bz2
>lilypond-2.21.0-1.darwin-x86.tar.bz2
>lilypond-2.21.0-1.freebsd-64.sh
>lilypond-2.21.0-1.freebsd-x86.sh
>lilypond-2.21.0-1.linux-64.sh
>lilypond-2.21.0-1.linux-ppc.sh
>lilypond-2.21.0-1.linux-x86.sh
>lilypond-2.21.0-1.mingw.exe
>lilypond-2.21.0.tar.gz
> 
> Please test if those files provide valid lilypond installations and report 
> success / failure by replying to this thread if no identical test results 
> already have been posted.

I downloaded and installed lilypond-2.21.0-1.linux-64.sh.
Running this on a couple of scores, things looked fine.
(One slight spacing difference in comparison with 2.19.80.)

The tree of files has some differences, but I don't know enough
about where things should be to have an opinion on what's right/better.

The only thing that might concern you is that I went to the web page
above, RightClicked on the file I wanted, selected 'Copy link location'
and pasted the result as the target of wget.

Here's the resulting dialogue:

$ wget 
https://cloud.ursliska.de/s/QPINwLqJNeVslCu/download?path=%2F=lilypond-2.21.0-1.linux-64.sh
[1] 24275
$ --2019-01-29 12:58:33-- 
https://cloud.ursliska.de/s/QPINwLqJNeVslCu/download?path=%2F
Resolving cloud.ursliska.de (cloud.ursliska.de)... 85.25.3.15
Connecting to cloud.ursliska.de (cloud.ursliska.de)|85.25.3.15|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: ‘download?path=%2F’

download?path=%2F[<=>] 245.60M  
2.14MB/sin 2m 48s

2019-01-29 13:01:24 (1.46 MB/s) - ‘download?path=%2F’ saved [257530138]

^C
[1]+  Done  wget 
https://cloud.ursliska.de/s/QPINwLqJNeVslCu/download?path=%2F
$ 

In other words, I got the lot. It doesn't concern me, but you might
prefer less traffic on the site.

Archive:  download?path=%2F
  Length  DateTimeName
-  -- -   
0  2019-01-29 18:58   gub/
 26609979  2019-01-29 07:36   gub/lilypond-2.21.0-1.darwin-ppc.tar.bz2
 26597456  2019-01-29 07:37   gub/lilypond-2.21.0-1.darwin-x86.tar.bz2
 31320357  2019-01-29 07:38   gub/lilypond-2.21.0-1.freebsd-64.sh
 28015239  2019-01-29 07:38   gub/lilypond-2.21.0-1.freebsd-x86.sh
 31292293  2019-01-29 07:39   gub/lilypond-2.21.0-1.linux-64.sh
 30542915  2019-01-29 07:40   gub/lilypond-2.21.0-1.linux-ppc.sh
 31158331  2019-01-29 07:41   gub/lilypond-2.21.0-1.linux-x86.sh
 34771252  2019-01-29 07:42   gub/lilypond-2.21.0-1.mingw.exe
 17220012  2019-01-29 07:35   gub/lilypond-2.21.0.tar.gz
- ---
257527834 10 files

Cheers,
David.

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


Re: Please test new lilypond installers

2019-01-29 Thread David Wright
On Tue 29 Jan 2019 at 13:56:00 (-0600), David Wright wrote:
> On Tue 29 Jan 2019 at 10:19:33 (+0100), Knut Petersen wrote:
> > Hi everybody
> > 
> > Urs Liska provides installers for branch master of lilypond, generated by 
> > an updated version of our build system GUB:
> > 
> >https://cloud.ursliska.de/s/QPINwLqJNeVslCu
> > 
> > There you'll find
> > 
> >lilypond-2.21.0-1.darwin-ppc.tar.bz2
> >lilypond-2.21.0-1.darwin-x86.tar.bz2
> >lilypond-2.21.0-1.freebsd-64.sh
> >lilypond-2.21.0-1.freebsd-x86.sh
> >lilypond-2.21.0-1.linux-64.sh
> >lilypond-2.21.0-1.linux-ppc.sh
> >lilypond-2.21.0-1.linux-x86.sh
> >lilypond-2.21.0-1.mingw.exe
> >lilypond-2.21.0.tar.gz
> > 
> > Please test if those files provide valid lilypond installations and report 
> > success / failure by replying to this thread if no identical test results 
> > already have been posted.
> 
> I downloaded and installed lilypond-2.21.0-1.linux-64.sh.
> Running this on a couple of scores, things looked fine.

And just the same with lilypond-2.21.0-1.linux-x86.sh,
both these on Debian 9 stretch.

Cheers,
David.

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


Re: output-distance.py: Support relative font paths. (issue 349090043 by lemzw...@googlemail.com)

2019-01-29 Thread nhoc1990q1

On 2019/01/29 17:23:01, nhoc1990q1 wrote:

On 2019/01/13 02:37:05, 浪漫 Joachim Metz的老婆 wrote:
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E
> 
> vợ tôi
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> Tập lệnh tập tin / build / output-distance.py
(trái):
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#oldcode630%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> script / build / output-distance.py: 630: cho oldnew in (0,
1):
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#oldcode633%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> scripts / build / output-distance.py: 633: cho f trong global.glob
(pat):
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> Tập lệnh tập tin / build / output-distance.py
(phải):
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode632%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> scripts / build / output-distance.py: 632: # Các tệp EPS được tạo để

kiểm tra

hồi quy
inherit;">
style="vertical-align: inherit;">
> không chứa phông chữ
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode633%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> scripts / build / output-distance.py: 633: # để tiết kiệm dung lượng

đĩa.

Thay vào đó, đường dẫn
đến
inherit;">
style="vertical-align: inherit;">
> các phông chữ được lưu trữ trong
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode634%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> scripts / build / output-distance.py: 634: # các tệp được tải
bởi
inherit;">
style="vertical-align: inherit;">
> Ghostscript `.loadfont '
>

https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> vợ tôi
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode638%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> script / build / output-distance.py: 638: # location của các tệp EPS

cụ thể.


inherit;">
style="vertical-align: inherit;">
> Vì gs không
> https://photos.app.goo.gl/KCakjdAeKg6WSURT%3Cfont%3E%3C/font%3E
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode639%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> scripts / build / output-distance.py: 639: # cung cấp tùy chọn điều

chỉnh

phông chữ
inherit;">
style="vertical-align: inherit;">
> đường dẫn tra cứu cho
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode640%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> scripts / build / output-distance.py: 640: # `.loadfont ', chúng tôi

vào thư

mục để
inherit;">
style="vertical-align: inherit;">
> rằng các đường dẫn tương đối
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7%3Cfont%3E%3C/font%3E
> 
>


https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode640%3Cfont%3E%3C/font%3E%3Cfont

style="vertical-align: inherit;">
inherit;">

> scripts / build / output-distance.py: 640: # `.loadfont ', chúng tôi

vào thư

mục để
inherit;">
style="vertical-align: inherit;">
> rằng các đường dẫn tương đối
> https://photos.app.goo.gl/KCakjdAeKg6WSURT7




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


Re: output-distance.py: Support relative font paths. (issue 349090043 by lemzw...@googlemail.com)

2019-01-29 Thread nhoc1990q1

On 2019/01/13 02:37:05, 浪漫 Joachim Metz的老婆 wrote:

https://photos.app.goo.gl/KCakjdAeKg6WSURT7

style="vertical-align: inherit;">

vợ tôi



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py

Tập lệnh tập tin / build / output-distance.py

(trái):




https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#oldcode630

script / build / output-distance.py: 630: cho oldnew in (0,

1):

https://photos.app.goo.gl/KCakjdAeKg6WSURT7



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#oldcode633

scripts / build / output-distance.py: 633: cho f trong global.glob

(pat):

https://photos.app.goo.gl/KCakjdAeKg6WSURT7



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py

Tập lệnh tập tin / build / output-distance.py

(phải):




https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode632

scripts / build / output-distance.py: 632: # Các tệp EPS được tạo để

kiểm tra hồi quy

không chứa phông chữ
https://photos.app.goo.gl/KCakjdAeKg6WSURT7



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode633

scripts / build / output-distance.py: 633: # để tiết kiệm dung lượng

đĩa. Thay vào đó, đường
dẫn đến

các phông chữ được lưu trữ trong
https://photos.app.goo.gl/KCakjdAeKg6WSURT7



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode634

scripts / build / output-distance.py: 634: # các tệp được tải

bởi

Ghostscript `.loadfont '
https://photos.app.goo.gl/KCakjdAeKg6WSURT7
style="vertical-align: inherit;">

vợ tôi



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode638

script / build / output-distance.py: 638: # location của các tệp EPS

cụ thể. 

Vì gs không
https://photos.app.goo.gl/KCakjdAeKg6WSURT



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode639

scripts / build / output-distance.py: 639: # cung cấp tùy chọn điều

chỉnh phông chữ

đường dẫn tra cứu cho
https://photos.app.goo.gl/KCakjdAeKg6WSURT7



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode640

scripts / build / output-distance.py: 640: # `.loadfont ', chúng tôi

vào thư mục để

rằng các đường dẫn tương đối
https://photos.app.goo.gl/KCakjdAeKg6WSURT7



https://codereview.appspot.com/349090043/diff/20001/scripts/build/output-distance.py#newcode640

scripts / build / output-distance.py: 640: # `.loadfont ', chúng tôi

vào thư mục để

rằng các đường dẫn tương đối
https://photos.app.goo.gl/KCakjdAeKg6WSURT7




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


Re: Please test new lilypond installers

2019-01-29 Thread Michael Käppler

Am 29.01.2019 um 10:19 schrieb Knut Petersen:


lilypond-2.21.0-1.linux-64.sh


Works fine, Ubuntu 18.04.1 LTS, Kernel 4.15.0-36-generic running as
guest in VirtualBox 5.2.22 r126460, host Windows 10 Version 1803.


lilypond-2.21.0-1.mingw.exe


Works fine too, Windows 10 Version 1803.

Thank you all for your great work!

Michael

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


Re: Please test new lilypond installers

2019-01-29 Thread Paul Morris

On 1/29/19 1:24 PM, David Kastrup wrote:


Paul Morris  writes:


On 1/29/19 4:19 AM, Knut Petersen wrote:


lilypond-2.21.0-1.linux-64.sh

Installed on Ubuntu 18.04.1 LTS and tested with a couple of
pieces. Everything appears to be working fine.

Thanks to all for the work on GUB and the next stable LilyPond release!

Well, 21.0 is the next unstable release...


Ah, yes, I didn't intend to imply otherwise, but I see how what I wrote 
could have been misleading.  (I was just thinking along the lines of 
'work on GUB contributes to the release of the next stable', but I may 
not be fully aware of all the details there.)


Thanks for the clarification.

-Paul


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


Re: Please test new lilypond installers

2019-01-29 Thread Hans Åberg


> On 29 Jan 2019, at 20:00, Urs Liska  wrote:
> 
> If you use alternative notation fonts you have to "install" them for every 
> new LilyPond installation.

On MacOS it used used to work installing as a system font, and then only once 
is required. Tried with Bravura.otf.



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


Re: Please test new lilypond installers

2019-01-29 Thread Urs Liska



Am 29. Januar 2019 19:47:07 MEZ schrieb Michael Hendry 
:
>> On 29 Jan 2019, at 09:19, Knut Petersen 
>wrote:
>> 
>> Hi everybody
>> 
>> Urs Liska provides installers for branch master of lilypond,
>generated by an updated version of our build system GUB:
>> https://cloud.ursliska.de/s/QPINwLqJNeVslCu
>> There you'll find
>> lilypond-2.21.0-1.darwin-ppc.tar.bz2
>> lilypond-2.21.0-1.darwin-x86.tar.bz2
>> lilypond-2.21.0-1.freebsd-64.sh
>> lilypond-2.21.0-1.freebsd-x86.sh
>> lilypond-2.21.0-1.linux-64.sh
>> lilypond-2.21.0-1.linux-ppc.sh
>> lilypond-2.21.0-1.linux-x86.sh
>> lilypond-2.21.0-1.mingw.exe
>> lilypond-2.21.0.tar.gz
>> Please test if those files provide valid lilypond installations and
>report success / failure by replying to this thread if no identical
>test results already have been posted.
>> 
>> Knut
>> ___
>> lilypond-user mailing list
>> lilypond-u...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>Failed with a previously successfully compiled leadsheet file. Same
>result after running convert.ly.
>
>Michael
>
>
> Starting lilypond 2.21.0 [Swing 39.ly]...
>Processing `/Users/michaelhendry/LilyPond Working/Swing 39/Swing 39.ly'
>Parsing...
>Interpreting
>music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][224]
>Preprocessing graphical objects...
>fatal error: cannot find font: `lilyjazz-11'
>Exited with return code 1.

If you use alternative notation fonts you have to "install" them for every new 
LilyPond installation.

>___
>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: Please test new lilypond installers

2019-01-29 Thread Michael Hendry
> On 29 Jan 2019, at 09:19, Knut Petersen  wrote:
> 
> Hi everybody
> 
> Urs Liska provides installers for branch master of lilypond, generated by an 
> updated version of our build system GUB:
> https://cloud.ursliska.de/s/QPINwLqJNeVslCu
> There you'll find
> lilypond-2.21.0-1.darwin-ppc.tar.bz2
> lilypond-2.21.0-1.darwin-x86.tar.bz2
> lilypond-2.21.0-1.freebsd-64.sh
> lilypond-2.21.0-1.freebsd-x86.sh
> lilypond-2.21.0-1.linux-64.sh
> lilypond-2.21.0-1.linux-ppc.sh
> lilypond-2.21.0-1.linux-x86.sh
> lilypond-2.21.0-1.mingw.exe
> lilypond-2.21.0.tar.gz
> Please test if those files provide valid lilypond installations and report 
> success / failure by replying to this thread if no identical test results 
> already have been posted.
> 
> Knut
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

PS Apologies, should have said I’m using an iMac with High Sierra, and had 
launched the compilation from Frescobaldi.

Michael


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


Re: Please test new lilypond installers

2019-01-29 Thread Michael Hendry
> On 29 Jan 2019, at 09:19, Knut Petersen  wrote:
> 
> Hi everybody
> 
> Urs Liska provides installers for branch master of lilypond, generated by an 
> updated version of our build system GUB:
> https://cloud.ursliska.de/s/QPINwLqJNeVslCu
> There you'll find
> lilypond-2.21.0-1.darwin-ppc.tar.bz2
> lilypond-2.21.0-1.darwin-x86.tar.bz2
> lilypond-2.21.0-1.freebsd-64.sh
> lilypond-2.21.0-1.freebsd-x86.sh
> lilypond-2.21.0-1.linux-64.sh
> lilypond-2.21.0-1.linux-ppc.sh
> lilypond-2.21.0-1.linux-x86.sh
> lilypond-2.21.0-1.mingw.exe
> lilypond-2.21.0.tar.gz
> Please test if those files provide valid lilypond installations and report 
> success / failure by replying to this thread if no identical test results 
> already have been posted.
> 
> Knut
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

Failed with a previously successfully compiled leadsheet file. Same result 
after running convert.ly.

Michael


 Starting lilypond 2.21.0 [Swing 39.ly]...
Processing `/Users/michaelhendry/LilyPond Working/Swing 39/Swing 39.ly'
Parsing...
Interpreting 
music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][224]
Preprocessing graphical objects...
fatal error: cannot find font: `lilyjazz-11'
Exited with return code 1.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Please test new lilypond installers

2019-01-29 Thread David Kastrup
Paul Morris  writes:

> On 1/29/19 4:19 AM, Knut Petersen wrote:
>
>> lilypond-2.21.0-1.linux-64.sh
>
> Installed on Ubuntu 18.04.1 LTS and tested with a couple of
> pieces. Everything appears to be working fine.
>
> Thanks to all for the work on GUB and the next stable LilyPond release!

Well, 21.0 is the next unstable release...

-- 
David Kastrup

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


Re: Please test new lilypond installers

2019-01-29 Thread Paul Morris

On 1/29/19 4:19 AM, Knut Petersen wrote:


lilypond-2.21.0-1.linux-64.sh


Installed on Ubuntu 18.04.1 LTS and tested with a couple of pieces. 
Everything appears to be working fine.


Thanks to all for the work on GUB and the next stable LilyPond release!

-Paul


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


Re: Please test gub

2019-01-29 Thread Karlin High
On Tue, Jan 29, 2019 at 8:25 AM Phil Holmes  wrote:
>
> Could someone pint me to what I
> need to do in order to get the gub git stash up to date and correct?

Lots of things happening with GUB lately. Major discussion threads include:
"I cannot run make check since Issue 5450: relocate.cc: Introduce new
command `set?'"

"gub: I can now completely build LilyPond"


For GUB development, pull requests 53-60 are being tested.


For convenience of testers, Knut Petersen cloned the repository,
merged the pending pull requests, and wrote instructions for testing.



I expect "up to date and correct" as used in the request means "a
state that will allow new official builds of LilyPond." I'll leave
that for others to answer. At the moment, the choices of GUB
repositories seem to be "broken" and "incompletely tested, but hopeful
of late."
-- 
Karlin High
Missouri, USA

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


Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

2019-01-29 Thread dak

On 2019/01/28 21:53:04, dak wrote:

On 2019/01/28 20:02:53, Valentin Villenave wrote:



> I can’t figure out how to make it work without resetting the

EventChord’s

> elements list. How would you proceed?



Without any pointer to what you are having problems with, this is

essentially

"do it yourself".  Sigh.  I don't even understand what those

interfaces are

supposed to be good for so I at least changed the internals to stop

chaotically

mixing directions and counts.  The user-level commands remain as

chaotic as I

find them to be.



Try this patched-up variant of code posted in the mailing list.



%



\version "2.21.0"



#(define-public (move-chord-note n octs)
(_i "Transpose a note (numbered as @var{n}) by @var{octs} octaves.
@var{n} is zero-based and can be negative to count from the end.")
(lambda (music)
  (define (proper-pitch note)
(let* ((oct (ly:music-property note 'octavation))
  (pitch (ly:music-property note 'pitch)))
 (if (number? oct)
 (ly:pitch-transpose pitch (ly:make-pitch oct 0))
 pitch)))


Well, considering the way invertChords is written, this should likely
just be
(define (proper-pitch note) (ly:music-property note 'pitch))
since "octavation" is only informational without affecting the pitch.
Thinko, sorry.

By the way, I find it somewhat strange that the code discussion on the
user list as well as the patch progress here completely ignore this
contribution.  After all, it was solicited.

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


Re: Emacs lilypond mode

2019-01-29 Thread Werner LEMBERG


>> What I want to know, however, is the `significance threshold' such
>> courtesy messages should have.
> 
> Pretty much any commit you are about to push to staging.  It's as
> simple as that.

OK, deal.


Werner

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


Re: Please test gub

2019-01-29 Thread Phil Holmes

[snip]

Please note that I've been out of the country for the last 3 weeks or so and 
haven't been following all the gub threads.  Could someone pint me to what I 
need to do in order to get the gub git stash up to date and correct?


FWIW I did get gub running just before I went away by dint of using the 
username gub and the directory NewGub for the build.  Didn't have time to 
build a release but hope to do so once I've tidied up after my holiday.


--
Phil Holmes


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


PATCHES - Countdown for January 29th

2019-01-29 Thread James Lowe
Hello,

Here is the current patch countdown list. The next countdown will be on 
the February 1st

A quick synopsis of all patches currently in the review process can be 
found here:

http://philholmes.net/lilypond/allura/


Push: No patches to push at this time.


Countdown:

5467 Fix make check without extractpdfmark - Masamichi Hosoda
https://sourceforge.net/p/testlilyissues/issues/5467
http://codereview.appspot.com/349110043

5465 Doc: add markup objects overview - Valentin Villenave
https://sourceforge.net/p/testlilyissues/issues/5465
http://codereview.appspot.com/357930043


Review:

5468 yyout2grammar.py: Various fixes. - Werner LEMBERG
https://sourceforge.net/p/testlilyissues/issues/5468
http://codereview.appspot.com/349120043

5464 New feature: automatically invert chords or drop/rise chord notes - 
Valentin Villenave
https://sourceforge.net/p/testlilyissues/issues/5464
http://codereview.appspot.com/365840043


New:

5469 Add `TEX` environemnt variable for texi2pdf - Masamichi Hosoda
https://sourceforge.net/p/testlilyissues/issues/5469
http://codereview.appspot.com/353870043




Regards


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


Re: Please test gub

2019-01-29 Thread Knut Petersen

On 29.01.19 14:30, Urs Liska wrote:


Looks like 64-bit Ubuntu, like my main machine. With an earlier
gub-version I had similiar problem, because of missing 32-bit
libraries.
I got further after installing:
lib32ncurses5
lib32z1


I suspect that

apt-get install libc6-dev-i386

fixes the problem on ubuntu 18.04



I installed the two packages Harm mentioned, and now it seems to be running 
pretty successfully. I'll report back when it finishes

Neither libn32curses5 nor lib32z1 are installed in my ubuntu 18.04 chroot environment that succeeds to finish gub runs, so these libs seem to be not required. Probably they pull in something we need. I verified that  removing libc6-dev-i386 and the libs it pulls in breaks building. But the question 
which libs are required can probably best be answered with the help of strace.


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


Re: Please test gub

2019-01-29 Thread Federico Bruni




Il giorno mar 29 gen 2019 alle 14:28, Knut Petersen 
 ha scritto:

On 29.01.19 11:56, Thomas Morley wrote:
Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High 
mailto:karlinh...@gmail.com>>:

On 1/28/2019 6:53 AM, Knut Petersen wrote:

Please report success / fails with os / version / cpu info.
I really like the simple instructions you posted, Knut. I wouldn't 
be

testing Gub without them. My setup doesn't like the
darwin-ppc::odcctools package for some reason. Mystified why it's
bringing in iPhone stuff. This same thing happened in 2 separate 
runs; I

had deleted the cloned Git repository and started over.

Windows 7 Pro 64-bit SP1, Intel Core i5-3450
VirtualBox 5.2.22r126460
VM with 1 CPU core, 4GB RAM, 64GB storage

karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename:   bionic

karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$uname -a
Linux vbox-ubuntu 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 
14:45:28

UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Looks like 64-bit Ubuntu, like my main machine. With an earlier
gub-version I had similiar problem, because of missing 32-bit
libraries.
I got further after installing:
lib32ncurses5
lib32z1


I suspect that

   apt-get install libc6-dev-i386

fixes the problem on ubuntu 18.04



Harm, see also:
https://github.com/fedelibre/LilyDev/blob/master/mkosi/debian/mkosi.postinst#L51




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


Re: Please test gub

2019-01-29 Thread Urs Liska



Am 29.01.19 um 14:28 schrieb Knut Petersen:

On 29.01.19 11:56, Thomas Morley wrote:

Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High:

On 1/28/2019 6:53 AM, Knut Petersen wrote:

Please report success / fails with os / version / cpu info.

I really like the simple instructions you posted, Knut. I wouldn't be
testing Gub without them. My setup doesn't like the
darwin-ppc::odcctools package for some reason. Mystified why it's
bringing in iPhone stuff. This same thing happened in 2 separate runs; I
had deleted the cloned Git repository and started over.

Windows 7 Pro 64-bit SP1, Intel Core i5-3450
VirtualBox 5.2.22r126460
VM with 1 CPU core, 4GB RAM, 64GB storage

karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename:   bionic

karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$uname -a
Linux vbox-ubuntu 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Looks like 64-bit Ubuntu, like my main machine. With an earlier
gub-version I had similiar problem, because of missing 32-bit
libraries.
I got further after installing:
lib32ncurses5
lib32z1


I suspect that

apt-get install libc6-dev-i386

fixes the problem on ubuntu 18.04



I installed the two packages Harm mentioned, and now it seems to be 
running pretty successfully. I'll report back when it finishes


Urs

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


Re: Please test gub

2019-01-29 Thread Karlin High

On 1/28/2019 11:28 PM, Federico Bruni wrote:
More likely a download went wrong and the tar.gz file is not really a 
tar.gz file.


/Gerade da ist das Problem./

It turns out that my gateway antivirus (Untangle, ClamAV I think) 
doesn't like the odcctools file. The download had returned an HTML block 
page instead. Temporarily disabled antivirus, got over that one.


Then I got the same problem Harm mentioned.

building package: darwin-ppc::odcctools
[...]
sh: 1: ./32bit: not found
error: cannot run 32 bit executable: 32bit
[...]
Exception: Package Odcctools depends on 32 bit libraries

As advised, I installed lib32ncurses5 and lib32z1, which brought in 
lib32tinfo5 and libc6-i386 as dependencies. According to Knut, that 
libc6-i386 might be what's actually required?


Off and running again for now, currently building package 
darwin-ppc::cross/gcc

--
Karlin High
Missouri, USA

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


Re: Please test gub

2019-01-29 Thread Knut Petersen

On 29.01.19 11:56, Thomas Morley wrote:

Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High :

On 1/28/2019 6:53 AM, Knut Petersen wrote:

Please report success / fails with os / version / cpu info.

I really like the simple instructions you posted, Knut. I wouldn't be
testing Gub without them. My setup doesn't like the
darwin-ppc::odcctools package for some reason. Mystified why it's
bringing in iPhone stuff. This same thing happened in 2 separate runs; I
had deleted the cloned Git repository and started over.

Windows 7 Pro 64-bit SP1, Intel Core i5-3450
VirtualBox 5.2.22r126460
VM with 1 CPU core, 4GB RAM, 64GB storage

karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename:   bionic

karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$uname -a
Linux vbox-ubuntu 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Looks like 64-bit Ubuntu, like my main machine. With an earlier
gub-version I had similiar problem, because of missing 32-bit
libraries.
I got further after installing:
lib32ncurses5
lib32z1


I suspect that

   apt-get install libc6-dev-i386

fixes the problem on ubuntu 18.04
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Emacs lilypond mode

2019-01-29 Thread David Kastrup
Werner LEMBERG  writes:

>>> Formatting only.  No change in behaviour.
>> 
>> And grammar and wording changes in the comments and changes from ##
>> comments to # comments (which does not appear to make a difference
>> to Emacs though as opposed to comments in some other languages).
>
> Yes.  `#' and `##' were mixed up without a system.  I'm curious: is
> there any other programming language besides Lisp (and its dialects)
> where such a distinction is commonly used?

It's not even used in Lisp in general.  It is an Emacs convention and as
such used in several of its programming language supporting modes, but
it doesn't seem to be used in its Python mode.

-- 
David Kastrup

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


Re: Add `TEX` environemnt variable for texi2pdf (issue 353870043 by truer...@gmail.com)

2019-01-29 Thread knupero

I reverted pull request #59 on a local branch of gub. In the local
lilypond repository I created branch 3538700043 pointing to HEAD of
stable/2.20, and added the proposed patch to branch 353870043.

make LILYPOND_REPO_URL=git://golem/lilypond.git
LILYPOND_BRANCH=stable/2.20 lilypond

fails again as expected,

make LILYPOND_REPO_URL=git://golem/lilypond.git
LILYPOND_BRANCH=353870043 lilypond

builds fine.

So this does not only look good, it's proven to be good ;-)

Thanks, Masamichi!


https://codereview.appspot.com/353870043/

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


Re: Please test new lilypond installers

2019-01-29 Thread Karlin High

On 1/29/2019 3:19 AM, Knut Petersen wrote:

    lilypond-2.21.0-1.darwin-x86.tar.bz2


Works on MacBook Air (mid 2012) with Intel Core i5 and macOS Mojave 10.14.2
--
Karlin High
Missouri, USA

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


Re: Please test new lilypond installers

2019-01-29 Thread Trevor

Knut Petersen wrote 29/01/2019 09:19:33

Urs Liska provides installers for branch master of lilypond, generated by an 
updated version of our build system GUB:

   https://cloud.ursliska.de/s/QPINwLqJNeVslCu

There you'll find

   lilypond-2.21.0-1.darwin-ppc.tar.bz2
   lilypond-2.21.0-1.darwin-x86.tar.bz2
   lilypond-2.21.0-1.freebsd-64.sh
   lilypond-2.21.0-1.freebsd-x86.sh
   lilypond-2.21.0-1.linux-64.sh
   lilypond-2.21.0-1.linux-ppc.sh
   lilypond-2.21.0-1.linux-x86.sh
   lilypond-2.21.0-1.mingw.exe
   lilypond-2.21.0.tar.gz

Please test if those files provide valid lilypond installations and report 
success / failure by replying to this thread if no identical test results 
already have been posted.
The mingw.exe download appears to work fine in Frescobaldi running under 
Windows 10 Home on Intel Core i7-7500U cpu. I'll continue to use it for 
all future typesetting.


Looking good! Many thanks to David, Knut, Urs and all those involved in 
generating this release!


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


Re: Emacs lilypond mode

2019-01-29 Thread James Lowe
Hello,

On Tue, 29 Jan 2019 08:07:58 +0100 (CET), Werner LEMBERG  wrote:

> 
> >> Formatting only.  No change in behaviour.
> > 
> > And grammar and wording changes in the comments and changes from ##
> > comments to # comments (which does not appear to make a difference
> > to Emacs though as opposed to comments in some other languages).
> 
> Yes.  `#' and `##' were mixed up without a system.  I'm curious: is
> there any other programming language besides Lisp (and its dialects)
> where such a distinction is commonly used?
> 
> >> While in general I like a conservative approach to patches, there
> >> are situations where trivial changes like the commit in question –
> >> essentially whitespace only, with slight reformulations of comments
> >> – should be pushed directly to the repository.  I even think that
> >> they are not worth an e-mail to the list.
> > 
> > Stuff that has no issue number has no history to check.  There is no
> > opportunity marking it for backporting to the stable branch.
> 
> This is something I admittedly haven't thought of.  However, it again
> points to a major weakness of Rietveld not being able to display a
> series of commits separately...
> 
> What about changing the commit message so that preliminary commits are
> explicitly mentioned?  This should ease backporting.
> 
> >> I admit that unreviewed, direct commits to `staging' sometimes
> >> fail, and I have already caused some trouble.  However, reverting
> >> is rather easy with git.
> > 
> > You first need to find the culprit.  Then you need to figure out
> > what problem it was supposed to fix and why it wasn't flagged by the
> > regtests.
> 
> Yep.
> 
> > A notice "I pushed a formatting change to staging in preparation for
> > this issue" would have notified the patch master.  It also would
> > have avoided the problem that he might have tried checking the
> > second patch against an unchanged master while the first patch was
> > still making its way through staging.
> 
> Hmm.  A serious question: Is this *really* necessary?  My reasoning:
> 
> (1) I've already announced publicly that I'm going to work on the
> yyout2grammar script.  Given that `lilypond-devel' is a
> high-traffic list, announcing such trivial commits feels like
> posting digestion status messages on Facebook...
> 
> (2) I've waited with submitting the Rietveld issue until my
> preliminary change was in the *master* branch – since the patch
> master always have to start with a `git pull', there shouldn't be
> any problem of applying Rietveld stuff for testing.  Do I miss
> something?
> 
> > For better or worse, several people try keeping track of what
> > happens to LilyPond.  Giving notice on the mailing list even when
> > you are not considering the full-blown procedure for a particular
> > change of relevance is, if nothing else, a courtesy and nod to them.
> 
> Basically, I agree.  What I want to know, however, is the
> `significance threshold' such courtesy messages should have.  

Pretty much any commit you are about to push to staging. It's as simple as that.

While I can take things like minor typos or translation pushing changes, it can 
be quite hard making sure that all issues and rietvelds are properly accounted 
for and the admin done on any tracker issues (so that the trackers can be 
verified) without having to wonder if the checkin that has just merged to 
master has an issue or not for me to follow and check that the rest of the team 
are OK with it.

Typos in doc and translations aside, even just a 'would anyone mind me making 
this change  and pushing directly to staging' would if nothing else save me 
wasted time hunting for potential trackers that I may need to update.

>For my
> formatting stuff on the Python script, I considered it not significant
> enough.  Is there a single LilyPond developer who doesn't use the
> wonderful `gitk' tool (or one of its siblings) to check commits?

It isn't about checking what is and what is not in master, it is making sure 
that I - as someone who tests the patches fully (offers of help always welcome) 
and keeping a handle on significant patches in progress, so that developers 
don't have to care and can keep on developing.

I realise that some don't like the way we do things 
(rietveld/sourceforge/seemingly complicated patch submission process) but it 
does work, keeps developers developing, makes sure there are no suprises (more 
or less) and developersd wanting to move things up the patch process more 
quickly that others, for example when there are related issues that also need 
pushing, is not unheard of.

I don't want to start any bitterness, but just to make sure we don't slip into 
the old ways where we constantly broke staging/master or developers would get 
frustrated because their patches no longer applied for testing and needed 
rebasing.

Thanks for your understanding.

James
___
lilypond-devel mailing list

Re: Please test gub

2019-01-29 Thread Knut Petersen






Obviously filenames (STRACE/TP) will differ as they indicate the ID of 
the processes.

Please send me those two files and target/darwin-ppc/log/odcctools.log.



Which two files, the tar and gzip files in .../usr/bin?



No, target/darwin-ppc/log/odcctools.log and the two files STRACE/TP 
that were reported by grep ...

Knut


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


Re: Please test gub

2019-01-29 Thread Thomas Morley
Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High :
>
> On 1/28/2019 6:53 AM, Knut Petersen wrote:
> > Please report success / fails with os / version / cpu info.
>
> I really like the simple instructions you posted, Knut. I wouldn't be
> testing Gub without them. My setup doesn't like the
> darwin-ppc::odcctools package for some reason. Mystified why it's
> bringing in iPhone stuff. This same thing happened in 2 separate runs; I
> had deleted the cloned Git repository and started over.
>
> Windows 7 Pro 64-bit SP1, Intel Core i5-3450
> VirtualBox 5.2.22r126460
> VM with 1 CPU core, 4GB RAM, 64GB storage
>
> karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 18.04.1 LTS
> Release:18.04
> Codename:   bionic
>
> karlin@vbox-ubuntu ~/knut-gub/gub (DevelHead=)$uname -a
> Linux vbox-ubuntu 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28
> UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Looks like 64-bit Ubuntu, like my main machine. With an earlier
gub-version I had similiar problem, because of missing 32-bit
libraries.
I got further after installing:
lib32ncurses5
lib32z1

This former run failed lateron with a python issue, though.

Right now I retry with Knut's gub, still running. I expect results in
the evening, have to run for my regular job now...

Cheers,
  Harm
>
> building package: darwin-ppc::odcctools
>   *** Stage: download (odcctools, darwin-ppc)
>   *** Stage: untar (odcctools, darwin-ppc)
> Command barfed: tar -C
> /home/karlin/knut-gub/gub/target/darwin-ppc/src/odcctools-278
> --strip-component=1 -v -z -xf
> /home/karlin/knut-gub/gub/downloads/odcctools/odcctools-iphone-dev-278.tar.gz
>
> Tail of target/darwin-ppc/log/odcctools.log 
>  gzip: stdin: not in gzip format
>  tar: Child returned status 1
>  tar: Error is not recoverable: exiting now
>  Command barfed: tar -C
> /home/karlin/knut-gub/gub/target/darwin-ppc/src/odcctools-278
> --strip-component=1 -v -z -xf
> /home/karlin/knut-gub/gub/downloads/odcctools/odcctools-iphone-dev-278.tar.gz
>  Tail of target/darwin-ppc/log/odcctools.log
>
> *** Failed target: darwin-ppc::odcctools
> gub.make:63: recipe for target 'packages' failed
> make[1]: *** [packages] Error 1
> make[1]: Leaving directory '/home/karlin/knut-gub/gub'
> GNUmakefile:26: recipe for target 'lilypond' failed
> make: *** [lilypond] Error 2
>
> real76m18.221s
> user52m44.624s
> sys 8m14.693s
> --
> Karlin High
> Missouri, USA
>
> ___
> 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: Please test gub

2019-01-29 Thread Urs Liska

Hi Knut,

as said I ran the GUB build on my Debian server as well.

Am 29.01.19 um 08:11 schrieb Knut Petersen:

On 29.01.19 00:53, Karlin High wrote:

*** Failed target: darwin-ppc::odcctools
gub.make:63: recipe for target 'packages' failed
make[1]: *** [packages] Error 1
make[1]: Leaving directory '/home/karlin/knut-gub/gub'
GNUmakefile:26: recipe for target 'lilypond' failed
make: *** [lilypond] Error 2



It seems that one choked at exactly the same point.


That means you were able to build all the tools necessary to start 
compilation of odcctools. But our own gzip fails to decompress the 
odcc*tar.gz. Weird.


Please verify that you got the correct source file. Executing

   md5sum downloads/odcctools/odcctools-iphone-dev-278.tar.gz

in  /home/karlin/knut-gub/gub should give that result:

   b067f6311e4c3d923e693dd280fab632 
downloads/odcctools/odcctools-iphone-dev-278.tar.gz



That's successful.




If this is ok (it really should!) please execute the following commands:

   mkdir -p STRACE
   rm -f STRACE/*
   rm -f target/darwin-ppc/packages/odcctools*



It seems I also had to remove target/darwin-ppc/status/odcctools*



strace -v -f -ff -s 1024 -o STRACE/TP bin/gub darwin-ppc::odcctools
   grep -o '^exec[^]]*]' STRACE/*  |  grep '/tar"\|/gzip"'

the output of grep should be similar to

STRACE/TP.7751:execve("/home/gub/gub/target/tools/root/usr/bin/tar", 
["tar", "-C", "/home/gub/gub/target/darwin-ppc/src/odcctools-278", 
"--strip-component=1", "-v", "-z", "-xf", 
"/home/karlin/knut-gub/gub/downloads/odcctools/odcctools-iphone-dev-278.tar.gz"]
STRACE/TP.7752:execve("/home/gub/gub/target/tools/root/usr/bin/gzip", 
["gzip", "-d"]




It is.


Obviously filenames (STRACE/TP) will differ as they indicate 
the ID of the processes.


Please send me those two files and target/darwin-ppc/log/odcctools.log.



Which two files, the tar and gzip files in .../usr/bin?

Urs




Knut







___
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: Please test new lilypond installers

2019-01-29 Thread Karlin High
On Tue, Jan 29, 2019 at 3:20 AM Knut Petersen  wrote:
> lilypond-2.21.0-1.mingw.exe

Seems to work on Windows 10 Pro 64-bit version 1803.

And it's definitely LilyPond 2.21 because it choked on \partcombine
and needed \partCombine instead. Fixed with convert-ly.
--
Karlin High
Missouri, USA

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


Re: Please test gub

2019-01-29 Thread Federico Bruni
Il giorno mar 29 gen 2019 alle 7:41, Urs Liska  
ha scritto:

So what can I do to check whether make lilypond succeeded or failed?


Good question.

On Ubuntu 16.04...
I just found out that I managed to build the packages on 23rd of 
January,

despite the errors I reported last week:

$ ls -lh uploads/
total 247M
-rw-rw-r-- 1 dev dev 26M Jan 28 20:23 
lilypond-2.21.0-1.darwin-ppc.tar.bz2
-rw-rw-r-- 1 dev dev 26M Jan 23 13:30 
lilypond-2.21.0-1.darwin-x86.tar.bz2

-rwxr-xr-x 1 dev dev 30M Jan 23 13:35 lilypond-2.21.0-1.freebsd-64.sh
-rwxr-xr-x 1 dev dev 27M Jan 23 13:35 lilypond-2.21.0-1.freebsd-x86.sh
-rwxr-xr-x 1 dev dev 30M Jan 23 13:33 lilypond-2.21.0-1.linux-64.sh
-rwxr-xr-x 1 dev dev 30M Jan 23 13:34 lilypond-2.21.0-1.linux-ppc.sh
-rwxr-xr-x 1 dev dev 30M Jan 28 20:23 lilypond-2.21.0-1.linux-x86.sh
-rw-rw-r-- 1 dev dev 34M Jan 23 13:32 lilypond-2.21.0-1.mingw.exe
-rw-rw-r-- 1 dev dev 17M Jan 23 13:36 lilypond-2.21.0.tar.gz
drwxrwxr-x 2 dev dev 4.0K Jan 23 13:36 signatures


Yesterday (28th) I ran a new 'make lilypond' after cleaning target/ and 
pulling
Knut's branch. It seems that I managed to rebuild linux-x86 and 
darwin-ppc, but

darwin-x86 failed.

Find attached log/gub.log

Here's the terminal output tail:

building package: linux-x86::lilypond-installer
*** Stage: download (lilypond-installer, linux-x86)
*** Stage: compile (lilypond-installer, linux-x86)
*** Stage: install (lilypond-installer, linux-x86)
*** Stage: package (lilypond-installer, linux-x86)

done
calculating dependencies
Checking for mpost ... /usr/bin/mpost
Checking for xelatex ... /usr/bin/xelatex
Checking for g++ ... /usr/bin/g++
Checking for mf ... /usr/bin/mf
Checking for xetex ... /usr/bin/xetex
Checking for gcc ... /usr/bin/gcc
must rebuild[darwin-ppc]: system::gcc system::g++ system::mpost 
system::mf system::xelatex system::xetex lilypond-installer

*** Stage: pkg_install (cross/gcc-core, linux-x86)
 cross/gcc conflicts with cross/gcc-core
   non-core cross/gcc already installed
 skipping request to install cross/gcc-core
 cross/gcc-doc conflicts with cross/gcc-core
   non-core cross/gcc already installed
 skipping request to install cross/gcc-core
 cross/gcc-runtime conflicts with cross/gcc-core
   non-core cross/gcc already installed
 skipping request to install cross/gcc-core

*** Stage: pkg_install (glibc-core, linux-x86)
 glibc conflicts with glibc-core
   non-core glibc already installed
 skipping request to install glibc-core
 glibc-doc conflicts with glibc-core
   non-core glibc already installed
 skipping request to install glibc-core

building package: darwin-ppc::lilypond-installer
*** Stage: download (lilypond-installer, darwin-ppc)
*** Stage: compile (lilypond-installer, darwin-ppc)
*** Stage: install (lilypond-installer, darwin-ppc)
*** Stage: package (lilypond-installer, darwin-ppc)

done
calculating dependencies
Checking for mpost ... /usr/bin/mpost
Checking for xelatex ... /usr/bin/xelatex
Checking for mf ... /usr/bin/mf
Checking for g++ ... /usr/bin/g++
Checking for xetex ... /usr/bin/xetex
Checking for gcc ... /usr/bin/gcc
must rebuild[darwin-x86]: system::gcc system::g++ system::mpost 
odcctools system::mf system::xelatex system::xetex lilypond-installer

removing outdated[darwin-x86]: odcctools

Tail of log/gub.log 
   calculating checksums
   must rebuild[darwin-x86]: system::gcc system::g++ system::mpost 
odcctools system::mf system::xelatex system::xetex lilypond-installer

   removing outdated[darwin-x86]: odcctools
   uninstalling package: odcctools-doc
 Tail of log/gub.log

Traceback (most recent call last):
 File "bin/gub", line 233, in exceptional_build
   build (settings, options, files)
 File "bin/gub", line 229, in build
   b.build_source_packages (names)
 File "bin/../gub/buildrunner.py", line 330, in build_source_packages
   self.uninstall_specs (outdated_installed)
 File "bin/../gub/buildrunner.py", line 309, in uninstall_specs
   self.uninstall_spec (self.specs[name])
 File "bin/../gub/buildrunner.py", line 299, in uninstall_spec
   self.manager (pkg.platform ()).uninstall_package (pkg.name ())
 File "bin/../gub/gup.py", line 340, in uninstall_package
   FileManager.uninstall_package (self, name)
 File "bin/../gub/gup.py", line 175, in uninstall_package
   lst = self.package_installed_files (name)
 File "bin/../gub/gup.py", line 81, in package_installed_files
   lst = self._package_file_db[name]
KeyError: 'odcctools-doc'
gub.make:69: recipe for target 'lilypond-installers' failed
make[1]: *** [lilypond-installers] Error 1
make[1]: Leaving directory '/home/dev/gub'
GNUmakefile:26: recipe for target 'lilypond' failed
make: *** [lilypond] Error 2

real 218m19.121s
user 367m57.214s
sys 67m46.505s





 * Starting build: Mon Jan 28 20:23:57 2019
root: /home/dev/gub/target/darwin-x86/root
platform: darwin-x86
calculating dependencies
reading spec: gub/specs/lilypond-installer.py
LOOKING FOR: Lilypond_installer__darwin__x86
cls:
module name: darwin
reading 

Please test new lilypond installers

2019-01-29 Thread Knut Petersen

Hi everybody

Urs Liska provides installers for branch master of lilypond, generated by an 
updated version of our build system GUB:

   https://cloud.ursliska.de/s/QPINwLqJNeVslCu

There you'll find

   lilypond-2.21.0-1.darwin-ppc.tar.bz2
   lilypond-2.21.0-1.darwin-x86.tar.bz2
   lilypond-2.21.0-1.freebsd-64.sh
   lilypond-2.21.0-1.freebsd-x86.sh
   lilypond-2.21.0-1.linux-64.sh
   lilypond-2.21.0-1.linux-ppc.sh
   lilypond-2.21.0-1.linux-x86.sh
   lilypond-2.21.0-1.mingw.exe
   lilypond-2.21.0.tar.gz

Please test if those files provide valid lilypond installations and report 
success / failure by replying to this thread if no identical test results 
already have been posted.

Knut

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


Re: Please test gub

2019-01-29 Thread Urs Liska

Hi Knut,

Am 29.01.19 um 10:02 schrieb Knut Petersen:


Hi Urs!


So what can I do to check whether make lilypond succeeded or failed?



The last lines of the terminal output will look like:

make -f lilypond.make update-versions

To upload, run:

    make lilypond-upload LILYPOND_BRANCH=master
LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git

 nsis rule
python bin/gub tools::nsis
calculating dependencies
Checking for iconv ... /usr/bin/iconv
Checking for g++ ... /usr/bin/g++
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc system::g++ system::iconv
 *** Stage: pkg_install (cross/gcc-core, linux-x86)
  cross/gcc conflicts with cross/gcc-core
    non-core cross/gcc already installed
  skipping request to install cross/gcc-core
  cross/gcc-doc conflicts with cross/gcc-core
    non-core cross/gcc already installed
  skipping request to install cross/gcc-core
  cross/gcc-runtime conflicts with cross/gcc-core
    non-core cross/gcc already installed
  skipping request to install cross/gcc-core

 *** Stage: pkg_install (glibc-core, linux-x86)
  glibc conflicts with glibc-core
    non-core glibc already installed
  skipping request to install glibc-core
  glibc-doc conflicts with glibc-core
    non-core glibc already installed
  skipping request to install glibc-core

done
 rest rule
 all rule
 Default rule
make[1]: Leaving directory `/home/knut/sources/gub'

if everything worked fine.



Indeed that's exactly how it looks like :-)


In uploads you see the generated installers, the documentation, test 
results etc:


drwxr-xr-x 2 knut users  4096 29. Jan 08:56 signatures
drwxr-xr-x 4 knut users  4096 29. Jan 08:56 localdoc
drwxr-xr-x 4 knut users  4096 29. Jan 08:56 webdoc
-rw-r--r-- 1 knut users 137828875 29. Jan 08:56
lilypond-2.21.0-1.webdoc.tar.bz2
-rw-r--r-- 1 knut users 158089031 29. Jan 08:55
lilypond-2.21.0-1.documentation.tar.bz2
drwxr-xr-x 4 knut users  4096 29. Jan 08:34 webtest
-rw-r--r-- 1 knut users  18416327 29. Jan 08:31
lilypond-2.21.0-1.test-output.tar.bz2
-rw-r--r-- 1 knut users  17226394 29. Jan 08:28 lilypond-2.21.0.tar.gz
-rwxr-xr-x 1 knut users  31251820 29. Jan 08:27
lilypond-2.21.0-1.freebsd-64.sh
-rwxr-xr-x 1 knut users  28063129 29. Jan 08:27
lilypond-2.21.0-1.freebsd-x86.sh
-rwxr-xr-x 1 knut users  30586997 29. Jan 08:27
lilypond-2.21.0-1.linux-ppc.sh
-rwxr-xr-x 1 knut users  31375293 29. Jan 08:27
lilypond-2.21.0-1.linux-64.sh
-rw-r--r-- 1 knut users  34665510 29. Jan 08:26
lilypond-2.21.0-1.mingw.exe
-rw-r--r-- 1 knut users  26746205 29. Jan 08:25
lilypond-2.21.0-1.darwin-x86.tar.bz2
-rw-r--r-- 1 knut users  26611149 29. Jan 08:25
lilypond-2.21.0-1.darwin-ppc.tar.bz2
-rwxr-xr-x 1 knut users  31208955 29. Jan 08:24
lilypond-2.21.0-1.linux-x86.sh

If you reached that point everything went fine.

At least we hope that everything went fine.

When we will start to update relevant components like guile we will 
need a way to test if the generated archives contain a working 
lilypond or garbage. I see that you already thought about that by 
providing the generated files on your cloud. Thanks you.




Right now I have the process running on my dedicated server running 
Debian 9.7 (so far running without errors, but I'll reattach to the 
session in the afternoon). If that works too I'd "donate" that server 
capacity for further and maybe automated tests, as long as I don't have 
to be involved in complicated set-ups or configuration. If necessary I 
could then also give someone (e.g. you) a non-privileged user account. 
But I'll report back when I have results from the current build.


Urs


Knut

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


Re: Please test gub

2019-01-29 Thread Knut Petersen

Hi Urs!


So what can I do to check whether make lilypond succeeded or failed?



The last lines of the terminal output will look like:

   make -f lilypond.make update-versions

   To upload, run:

    make lilypond-upload LILYPOND_BRANCH=master 
LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git

    nsis rule
   python bin/gub tools::nsis
   calculating dependencies
   Checking for iconv ... /usr/bin/iconv
   Checking for g++ ... /usr/bin/g++
   Checking for gcc ... /usr/bin/gcc
   must rebuild[tools]: system::gcc system::g++ system::iconv
 *** Stage: pkg_install (cross/gcc-core, linux-x86)
  cross/gcc conflicts with cross/gcc-core
    non-core cross/gcc already installed
  skipping request to install cross/gcc-core
  cross/gcc-doc conflicts with cross/gcc-core
    non-core cross/gcc already installed
  skipping request to install cross/gcc-core
  cross/gcc-runtime conflicts with cross/gcc-core
    non-core cross/gcc already installed
  skipping request to install cross/gcc-core

 *** Stage: pkg_install (glibc-core, linux-x86)
  glibc conflicts with glibc-core
    non-core glibc already installed
  skipping request to install glibc-core
  glibc-doc conflicts with glibc-core
    non-core glibc already installed
  skipping request to install glibc-core

   done
    rest rule
    all rule
    Default rule
   make[1]: Leaving directory `/home/knut/sources/gub'

if everything worked fine.

In uploads you see the generated installers, the documentation, test results 
etc:

   drwxr-xr-x 2 knut users  4096 29. Jan 08:56 signatures
   drwxr-xr-x 4 knut users  4096 29. Jan 08:56 localdoc
   drwxr-xr-x 4 knut users  4096 29. Jan 08:56 webdoc
   -rw-r--r-- 1 knut users 137828875 29. Jan 08:56 
lilypond-2.21.0-1.webdoc.tar.bz2
   -rw-r--r-- 1 knut users 158089031 29. Jan 08:55 
lilypond-2.21.0-1.documentation.tar.bz2
   drwxr-xr-x 4 knut users  4096 29. Jan 08:34 webtest
   -rw-r--r-- 1 knut users  18416327 29. Jan 08:31 
lilypond-2.21.0-1.test-output.tar.bz2
   -rw-r--r-- 1 knut users  17226394 29. Jan 08:28 lilypond-2.21.0.tar.gz
   -rwxr-xr-x 1 knut users  31251820 29. Jan 08:27 
lilypond-2.21.0-1.freebsd-64.sh
   -rwxr-xr-x 1 knut users  28063129 29. Jan 08:27 
lilypond-2.21.0-1.freebsd-x86.sh
   -rwxr-xr-x 1 knut users  30586997 29. Jan 08:27 
lilypond-2.21.0-1.linux-ppc.sh
   -rwxr-xr-x 1 knut users  31375293 29. Jan 08:27 lilypond-2.21.0-1.linux-64.sh
   -rw-r--r-- 1 knut users  34665510 29. Jan 08:26 lilypond-2.21.0-1.mingw.exe
   -rw-r--r-- 1 knut users  26746205 29. Jan 08:25 
lilypond-2.21.0-1.darwin-x86.tar.bz2
   -rw-r--r-- 1 knut users  26611149 29. Jan 08:25 
lilypond-2.21.0-1.darwin-ppc.tar.bz2
   -rwxr-xr-x 1 knut users  31208955 29. Jan 08:24 
lilypond-2.21.0-1.linux-x86.sh

If you reached that point everything went fine.

At least we hope that everything went fine.

When we will start to update relevant components like guile we will need a way 
to test if the generated archives contain a working lilypond or garbage. I see 
that you already thought about that by providing the generated files on your 
cloud. Thanks you.

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


Re: Please test gub

2019-01-29 Thread Urs Liska



Am 29.01.19 um 08:32 schrieb Werner LEMBERG:

If we get more success reports, the resulting packages should be
uploaded so that other people not running gub can test them.
Developers can then have a look how to add support for 64bit
binaries on MacOS and Windows.  Especially the former is rather
urgent...

I can upload my stuff, but what would that be?  I assume the
installer files are in the uploads directory, and I would upload all
the files that look like installers, but not the documentation
stuff, correct?

Yes.  In other words, the relevant files would be
`*.{sh,exe,tar.bz2}' but perhaps omitting
`lilypond-2.21.0-1.test-output.tar.bz2'.


 Werner



OK, the files will for some time be available from 
https://cloud.ursliska.de/s/QPINwLqJNeVslCu


They have been compiled on Linux Mint 19.1, 4.15.0-43-generic #46-Ubuntu 
SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


I think this post on this thread is not sufficient to promote the files 
for testing, so I suggest either you, Werner, or Knut keep this 
information and at some point throw out a more formal and wide-spread 
announcement asking for testing (probably better on lilypond-user than 
lilypond-devel.


Best
Urs


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