subject:"Re\: Please test gub"





On my system, your description matches: Current Master's musicxml2ly
python script runs fine using my local python2 (2.7.15rc1) but has
the error using 2.19.82's python2.4 (2.4.5).

Given that nobody is really working on musicxml2ly, I strongly suggest
that people start testing and using Jacques Menu's `xml2ly' program
instead:

   https://github.com/grame-cncm/libmusicxml/tree/lilypond

(i.e., the `lilypond' branch of the `libmusicxml' git repository).

AFAIK, the results are far superior to the `musicxml2ly' script.

Well, the situation is that (at least with currently shipped 2.19.82) 
there is a tool called musicxml2ly (which is also explicitly supported 
in Frescobaldi, so people might expect it to work) but which fails on 
execution.


I'm not well acquainted with the situation for 2.20 (e.g. which Python 
version might be shipped with it), but it seems to me that to have a 
well-documented tool shipped with LilyPond might be a show-stopper for a 
stable release.


I'm not sure I see the situation correctly, but the only ways forward I 
see would be to


1) make musicxml2ly work again (by changing the Python version used, or 
by fixing the problems with 2.4), or

2) remove musicxml2ly from the distribution bundle, possibly
2a) without replacement,
2b) replaced by xml2ly

Even if 2b) is the most attractive route in the long term, as you 
suggest, it seems to me that only 2a) and maybe 1) can be expected to 
happen soon enough for a stable release of 2.20. And I'm not sure 
whether 2a) would be a good idea.


I'm willing to try and help, but I'm not at all convinced that my very 
limited coding skills can be of much use here.


Lukas


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

Re: Please test gub

2019-02-09 Thread David Kastrup

Lukas-Fabian Moser  writes:

>>> For more than 10 years gub/specs/lilypond.py used
>>> /usr/bin/python. That means that during lilypond-test the system's
>>> python interpreter is used as the interpreter for the musicxml2ly
>>> script, not our own python in target/tools.  At some currently
>>> unknown point in time musicxml2ly became incompatible to our python
>>> 2.4. The hidden usage of the system's python masked that
>>> incompatibility.
>>>
>>> With our python 2.4 musicxml2ly does not barf, it simply produces
>>> garbage that lateron causes lilypond to fail.
>>>
> The error was introduced when John Gourlay copied changes made by
> Philomelos into the LilyPond git tree in commits
>
> 2ab5d80245dcab194daea64ec83ded3ec8252e51
> dc90b895668826a09e06ad1ef94e5e90569a870c
> da6591bef1cd9c684a9fb98f1563ea40c543ecdd
>
> in February 2016. Since these changes were copied as a bunch, one
> would probably have to delve into Philomelos's git tree or analyze the
> source directly.
>
> If you folks think it would be worth the effort, I could try to do this.

I think it would make more sense updating Python to 2.7 in Gub.  With a
few people currently looking at Gub, does that seem feasible?

-- 
David Kastrup

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

Re: Please test gub



For more than 10 years gub/specs/lilypond.py used /usr/bin/python. 
That means that during lilypond-test the system's python interpreter 
is used as the interpreter for the musicxml2ly script, not our own 
python in target/tools.  At some currently unknown point in time 
musicxml2ly became incompatible to our python 2.4. The hidden usage 
of the system's python masked that incompatibility.


With our python 2.4 musicxml2ly does not barf, it simply produces 
garbage that lateron causes lilypond to fail.


The error was introduced when John Gourlay copied changes made by 
Philomelos into the LilyPond git tree in commits


2ab5d80245dcab194daea64ec83ded3ec8252e51
dc90b895668826a09e06ad1ef94e5e90569a870c
da6591bef1cd9c684a9fb98f1563ea40c543ecdd

in February 2016. Since these changes were copied as a bunch, one would 
probably have to delve into Philomelos's git tree or analyze the source 
directly.


If you folks think it would be worth the effort, I could try to do this.

Lukas


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

Re: Please test gub

2019-02-09 Thread Werner LEMBERG



>> @Werner: Didn't you write something about updating python in gub?

Well, someone (I forgot his name) offered to work on updating python
to the latest 2.7.x version, which should make it easier to eventually
migrate to python 3.x...

> I assume you're referring to the situation that (e.g.) 2.19.82's
> musicxml2ly chokes with an error message regarding UTF-8 and
> producing ly files containing garbage bytes in each literal string.
> 
> On my system, your description matches: Current Master's musicxml2ly
> python script runs fine using my local python2 (2.7.15rc1) but has
> the error using 2.19.82's python2.4 (2.4.5).

Given that nobody is really working on musicxml2ly, I strongly suggest
that people start testing and using Jacques Menu's `xml2ly' program
instead:

  https://github.com/grame-cncm/libmusicxml/tree/lilypond

(i.e., the `lilypond' branch of the `libmusicxml' git repository).

AFAIK, the results are far superior to the `musicxml2ly' script.


Werner

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

Re: Please test gub


Hi,


-- 



5e44fec38f33997109bc85c099472b2736649fde is the first bad commit
commit 5e44fec38f33997109bc85c099472b2736649fde
Author: Frederic Gohier 
Date:   Thu May 10 11:12:44 2018 +0100

    Fix crash when using musicxml2ly

    Issue 5317
    Crash when running musicxml2ly

:04 04 32b11d27366ff7d629f2b6ca4d250a08293d6ece 
750f9ccdbec7fa68babf3f4414aecb70f57c812b M    python


-- 



So this might be the "currently unknown point in time"?


... I'm sorry, but this does not seem to be correct. It seems Frederic's 
commit fixed a crash that made the UTF-8 problem visible because one 
could not get to that point before.


So it seems one has to apply Frederic's change to older revisions as 
well in order to be able to bisect the UTF-8 problem. Is this possible 
with git?


Lukas


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

Re: Please test gub


Hi everybody,

For more than 10 years gub/specs/lilypond.py used /usr/bin/python. 
That means that during lilypond-test the system's python interpreter 
is used as the interpreter for the musicxml2ly script, not our own 
python in target/tools.  At some currently unknown point in time 
musicxml2ly became incompatible to our python 2.4. The hidden usage of 
the system's python masked that incompatibility.


With our python 2.4 musicxml2ly does not barf, it simply produces 
garbage that lateron causes lilypond to fail.


@Werner: Didn't you write something about updating python in gub?


I assume you're referring to the situation that (e.g.) 2.19.82's 
musicxml2ly chokes with an error message regarding UTF-8 and producing 
ly files containing garbage bytes in each literal string.


On my system, your description matches: Current Master's musicxml2ly 
python script runs fine using my local python2 (2.7.15rc1) but has the 
error using 2.19.82's python2.4 (2.4.5).


--

5e44fec38f33997109bc85c099472b2736649fde is the first bad commit
commit 5e44fec38f33997109bc85c099472b2736649fde
Author: Frederic Gohier 
Date:   Thu May 10 11:12:44 2018 +0100

    Fix crash when using musicxml2ly

    Issue 5317
    Crash when running musicxml2ly

:04 04 32b11d27366ff7d629f2b6ca4d250a08293d6ece 
750f9ccdbec7fa68babf3f4414aecb70f57c812b M    python


--

So this might be the "currently unknown point in time"?

Best
Lukas


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

Re: Please test gub

2019-02-08 Thread Knut Petersen

Hi everybody!

I think with the attached test-patch on top of the patch I already sent to you
'make lilypond' (not only bin/gub xxx::lilypond) should succeed after you put
the newly created wrapper directory in front of PATH.

I see; this wrapper directory is more convenient than asking the user to provide a
dir with only the symlinks python{,-config} -> /some/where/python2{,-config} on
his own and add it to the PATH.

But isn't it against the purpose that now the shebangs of bin/gub/* read

#! /usr/bin/env python2

? I think you meant: add the wrapper directory PATH such that we *don't* have
to replace python by python2 in those shebangs.

Yep, most if not all of those should be removed. I changed those files at a
time when I thought I would not need the wrappers.

-TARGET_PYTHON=/usr/bin/python
+TARGET_PYTHON=/usr/bin/env python

in gub/specs/lilypond{,-doc}.py (rather than python2) is necessary and (almost)
correct in the patch, though.

No, here I meant what I wrote, currently '/usr/bin/env python2' instead of the
original '/usr/bin/python' has to be used in lilypond.py and lilypond-doc.py

'/usr/bin/env python' should be the right solution, but it is not:

For more than 10 years gub/specs/lilypond.py used /usr/bin/python. That means that during lilypond-test the system's python interpreter is used as the interpreter for the musicxml2ly script, not our own python in target/tools. At some currently unknown point in time musicxml2ly became incompatible
to our python 2.4. The hidden usage of the system's python masked that incompatibility.

With our python 2.4 musicxml2ly does not barf, it simply produces garbage that
lateron causes lilypond to fail.

@Werner: Didn't you write something about updating python in gub?

Knut

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

Re: Please test gub

2019-02-08 Thread Werner LEMBERG



> - addition of texinfo/txi-pt.tex from Texinfo sources, as Portuguese
> translation has been added and I don't have Texinfo installed in GUB
> host system;

???  What exactly needs Portuguese?  Lilypond doesn't, AFAICS.

> - update of texinfo.tex (not necessary, but I did it together with
>   txi- pt.tex addition)

Yes, we should use `texinfo.tex' from texinfo's git repository, mainly
to fix a bug with `@verbatiminclude'
(http://lists.gnu.org/archive/html/bug-texinfo/2019-02/msg0.html),
which affects the display of the lilypond grammar.

> I've had some trouble doing non clean GUB builds, namely a Python
> KeyError with "odcctools-doc".

Yeah, it would be nice to know whether this is a Python issue that can
be corrected by using a newer version, or whether a gub programming
error.


Werner

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

Re: Please test gub

2019-02-08 Thread Alexander Kobel


On 08.02.19 14:12, Knut Petersen wrote:

Hi everybody!
 Use /usr/bin/env python2? Does every python 2.x installation 
really contain a python2 executable?
 OSX 10.12 Sierra has python 2.7 but does not have a python2 
executable.  Only python.


At least this is the case on my machine.


Gosh, didn't expect that.

In that case, I'd vote for leaving python shebangs as they are.

Arch is clearly not following (one of) the recommendation in the PEP, 
that python "should" deliver python2. So it's Arch's fault, and their 
(packagers/users') responsibility to take appropriate action.



Again, something to document ;-)

Gub itself does not provide a python2.

I think with the attached test-patch on top of the patch I already sent 
to you 'make lilypond' (not only bin/gub xxx::lilypond) should succeed 
after you put the newly created wrapper directory in front of PATH.


I see; this wrapper directory is more convenient than asking the user to 
provide a dir with only the symlinks python{,-config} -> 
/some/where/python2{,-config} on his own and add it to the PATH.


But isn't it against the purpose that now the shebangs of bin/gub/* read

#! /usr/bin/env python2

? I think you meant: add the wrapper directory PATH such that we *don't* 
have to replace python by python2 in those shebangs.


-TARGET_PYTHON=/usr/bin/python
+TARGET_PYTHON=/usr/bin/env python

in gub/specs/lilypond{,-doc}.py (rather than python2) is necessary and 
(almost) correct in the patch, though.



Cherry-picking only those changes, everything seems to start fine.


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-08 Thread Knut Petersen


Hi everybody!

 Use /usr/bin/env python2? Does every python 2.x installation really 
contain a python2 executable?
 OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.  
Only python.

At least this is the case on my machine.


Gosh, didn't expect that.

In that case, I'd vote for leaving python shebangs as they are.

Arch is clearly not following (one of) the recommendation in the PEP, that python 
"should" deliver python2. So it's Arch's fault, and their (packagers/users') 
responsibility to take appropriate action.


Again, something to document ;-)

Gub itself does not provide a python2.

I think with the attached test-patch on top of the patch I already sent to you 
'make lilypond' (not only bin/gub xxx::lilypond) should succeed after you put 
the newly created wrapper directory in front of PATH.

Knut

>From c17782911104845e818226c041d37e03f40d5759 Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Fri, 8 Feb 2019 00:30:10 +0100
Subject: [PATCH] Use /usr/bin/env and python2, provide wrappers

---
 bin/build-architecture  | 2 +-
 bin/build-platform  | 2 +-
 bin/cygwin-packager | 2 +-
 bin/gib | 2 +-
 bin/gpkg| 2 +-
 bin/gub | 2 +-
 bin/gub-tester  | 2 +-
 bin/gupdate | 2 +-
 gub/distcc.py   | 2 +-
 gub/runner.py   | 2 +-
 gub/specs/lilypond-doc.py   | 2 +-
 gub/specs/lilypond.py   | 4 ++--
 gub/versiondb.py| 2 +-
 gub/with-lock.py| 2 +-
 test-lily/cron-builder.py   | 2 +-
 test-lily/dist-check.py | 2 +-
 test-lily/rsync-lily-doc.py | 2 +-
 test-lily/rsync-test.py | 2 +-
 test-lily/test-binary.py| 2 +-
 test-lily/upload.py | 2 +-
 wrappers/python | 2 ++
 wrappers/python-config  | 2 ++
 22 files changed, 25 insertions(+), 21 deletions(-)
 create mode 100755 wrappers/python
 create mode 100755 wrappers/python-config

diff --git a/bin/build-architecture b/bin/build-architecture
index 7ea764ee..e68a4f6b 100755
--- a/bin/build-architecture
+++ b/bin/build-architecture
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 """
 Copyright (c) 2005--2008
diff --git a/bin/build-platform b/bin/build-platform
index bd7ddc8f..fcd950fe 100755
--- a/bin/build-platform
+++ b/bin/build-platform
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 """
 Copyright (c) 2005--2008
diff --git a/bin/cygwin-packager b/bin/cygwin-packager
index dbfd5c12..9099448a 100755
--- a/bin/cygwin-packager
+++ b/bin/cygwin-packager
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 
 """
diff --git a/bin/gib b/bin/gib
index 91d98b64..a7811f49 100755
--- a/bin/gib
+++ b/bin/gib
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 """
 Copyright (c) 2005--2008
diff --git a/bin/gpkg b/bin/gpkg
index bd3aab82..1d9892b2 100755
--- a/bin/gpkg
+++ b/bin/gpkg
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 """
 gpkg - GUB package manager
diff --git a/bin/gub b/bin/gub
index 261e7f90..011eee18 100755
--- a/bin/gub
+++ b/bin/gub
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 """
 Copyright (c) 2005--2008
diff --git a/bin/gub-tester b/bin/gub-tester
index 603fae12..2d0f070e 100755
--- a/bin/gub-tester
+++ b/bin/gub-tester
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 def argv0_relocation ():
 import os, sys
diff --git a/bin/gupdate b/bin/gupdate
index 08e6170d..1bb9a466 100755
--- a/bin/gupdate
+++ b/bin/gupdate
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 """
 Copyright (c) 2005--2009
diff --git a/gub/distcc.py b/gub/distcc.py
index d39451f7..a8b05942 100644
--- a/gub/distcc.py
+++ b/gub/distcc.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python2
 
 import os
 import re
diff --git a/gub/runner.py b/gub/runner.py
index 9399f352..7d426eec 100644
--- a/gub/runner.py
+++ b/gub/runner.py
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python2
 
 """
 Copyright (c) 2005--2007
diff --git a/gub/specs/lilypond-doc.py b/gub/specs/lilypond-doc.py
index 4123130c..1e98af0a 100644
--- a/gub/specs/lilypond-doc.py
+++ b/gub/specs/lilypond-doc.py
@@ -47,7 +47,7 @@ class LilyPond_doc (lilypond.LilyPond_base):
 CROSS=no
 DOCUMENTATION=yes
 WEB_TARGETS="offline online"
-TARGET_PYTHON=/usr/bin/python
+TARGET_PYTHON="/usr/bin/env python2"
 CPU_COUNT=%(cpu_count)s
 MISSING_OPTIONAL=dblatex
 ''')
diff --git a/gub/specs/lilypond.py b/gub/specs/lilypond.py
index 72117d70..e4778ed4 100644
--- a/gub/specs/lilypond.py
+++ b/gub/specs/lilypond.py
@@ -69,7 +69,7 @@ sheet music from a high-level description file.'''
+ ' --with-texgyre-dir=%(tools_prefix)s/share/fonts/opentype/texgyre'
+ ' --with-urwotf-dir=%(tools_prefix)s/share/fonts/opentype/urw-core35'
)
-make_flags = '

Re: Please test gub

2019-02-08 Thread Alexander Kobel

On 08.02.19 04:51, Carl Sorensen wrote:

On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen" 
 wrote:

 >> - the need to make sure that `python` calls a python2 interpreter.

 > No idea how this could be solved elegantly.  I guess it can't, so we
 > have again something to document...
 >
 Use /usr/bin/env python2? Does every python 2.x installation really 
contain a python2 executable?

OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.  Only python.

At least this is the case on my machine.

Gosh, didn't expect that.

In that case, I'd vote for leaving python shebangs as they are.

Arch is clearly not following (one of) the recommendation in the PEP, 
that python "should" deliver python2. So it's Arch's fault, and their 
(packagers/users') responsibility to take appropriate action.

Alex

smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-07 Thread Carl Sorensen

On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen" 
 wrote:

>> - the need to make sure that `python` calls a python2 interpreter.
> No idea how this could be solved elegantly.  I guess it can't, so we
> have again something to document...
>
Use /usr/bin/env python2? Does every python 2.x installation really contain 
a python2 executable?

OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.  Only 
python.

At least this is the case on my machine.

Thanks,

Carl

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

Re: Please test gub

2019-02-07 Thread John Mandereau

Hi Knut, hi folks,
On Mon 2019-01-28 13:53 +0100, Knut Petersen wrote:
> Please report success / fails with os / version / cpu info.

With this setup:
- PRs 53-60 (including update to PR 59 on January 27) applied to GUB,
- Ubuntu 14.05 LTS amd64, ran in a chroot from Fedora 29,
- an Intel Core 2 Duo E8500 at 3.16GHz

I had a build of LilyPond binaries, tests and docs without error in
about 8 hours, with master branch; I got also the same with stable/2.20
branch plus a couple of additional commits:
- addition of texinfo/txi-pt.tex from Texinfo sources, as Portuguese
translation has been added and I don't have Texinfo installed in GUB
host system;
- update of texinfo.tex (not necessary, but I did it together with txi-
pt.tex addition)
- application of Masamichi Hosoda patch for issue 5463;
- backport from master of "Add `TEX` environemnt variable for
texi2pdf".
I pushed the resulting branch to dev/jm-stable-2.20 so you may review
this.

I succesfully tested Linux-64 bit binary built from LilyPond master
branch on my Fedora 29 system, on a medium-sized sample.

As for documentation, the text in UTF-8 sample in Snippets is well
rendered in LilyPond output, but non-Latin1 text is not rendered in ly
code quotation in PDF format (this text is also screwed in last 2.19
release, whereas in 2.18 last release only Latin-1 and Cyrillic text is
rendered in ly source).

I've had some trouble doing non clean GUB builds, namely a Python
KeyError with "odcctools-doc".

I'll do other builds from scratch, testing newer pull requests on top
of #53-60, and will also make an attempt on Fedora 29 plus local
install of GCC 7 (with GCC 8 shipped with this distro, tools:guile GUB
build fails, and it seems hard to fix).

Best
-- 
John Mandereau


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

Re: Please test gub

2019-02-07 Thread Alexander Kobel


Hi,

On 06.02.19 23:31, Knut Petersen wrote:

On 06.02.19 15:09, Werner LEMBERG wrote:

That leaves the two problems of

- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
   (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

This is definitely *not* a gub issue.  It's strange that only the
compilation of guile is affected by the problem, but I consider this a
pure coincidence.  IOW, this should be added to the gub documentation,
as a special preparation step for some LLVM/binutils combinations.


I agree.


I have no idea regarding that issue and trust your assessment.


- the need to make sure that `python` calls a python2 interpreter.

No idea how this could be solved elegantly.  I guess it can't, so we
have again something to document...

Use /usr/bin/env python2? Does every python 2.x installation really 
contain a python2 executable?


Not sure, but according to PEP 394, they "should". The PEP dates back to 
2011, so I'd assume that all systems have a corresponding alias by now, 
and only the default `python` is different.


(IIUC, Gentoo follows Arch's example, see the bottom of 
https://wiki.gentoo.org/wiki/Python; do we have any Gentoo users here?)


Of course, Arch obviously disregards the PEP's first recommendation 
(python should point to python2), so it's perfectly fair to consider 
this entirely Arch's / Gentoo's fault. However, one of the good reasons 
Archers state to follow the explicit python2 / python3 spelling (and 
having python3 as default) is that python2 will see it's end of 
maintenance at the end of this year, and they plan to stop distributing 
python2 as a first-class citizen in the core repositories more or less 
immediately (it will still be easily available via community repos 
though). So following all of the PEP, you'd end up with a system that 
has python3, but neither python nor python2. Perhaps that's harsh, but 
it's a reasonable decision given that official support ends.


In the rationale, the PEP says

"As some of the former distributions did not provide a python2 command 
by default, there was previously no way for Python 2 code (or any code 
that invokes the Python 2 interpreter directly rather than via 
sys.executable) to reliably run on all Unix-like systems without 
modification, as the python command would invoke the wrong interpreter 
version on some systems, and the python2 command would fail completely 
on others."


so this might not be *entirely* smooth.
https://mail.python.org/pipermail/python-dev/2011-March/108491.html 
mentions Debian, Slack and BSDs; but AFAIK, all of those follow the PEP 
these days.



I think we also would need to change some lilypond files ...


FWIW, this is what is done in the Arch packaging process:

  for file in $(find . -name '*.py' -print); do
sed -i 's_^#!.*/usr/bin/python_#!/usr/bin/python2_' $file
sed -i 's_^#!.*/usr/bin/env.*python_#!/usr/bin/env python2_' $file
  done

  sed -i 's|GUILE_CFLAGS=.*|GUILE_CFLAGS="`pkg-config --cflags 
guile-1.8`"|' configure
  sed -i 's|GUILE_LDFLAGS=.*|GUILE_LDFLAGS="`pkg-config --libs 
guile-1.8`"|' configure


plus a patch regarding fontsizes; not sure what this is about:

https://git.archlinux.org/svntogit/community.git/tree/trunk/lilyfontsize.patch?h=packages/lilypond


It might be worth testing whether applying this patch upstream breaks 
anything for someone else; but of course, that's from an Arch user's 
perspective...



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-06 Thread Knut Petersen


On 06.02.19 15:09, Werner LEMBERG wrote:

That leaves the two problems of

- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
   (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

This is definitely *not* a gub issue.  It's strange that only the
compilation of guile is affected by the problem, but I consider this a
pure coincidence.  IOW, this should be added to the gub documentation,
as a special preparation step for some LLVM/binutils combinations.


I agree.



- the need to make sure that `python` calls a python2 interpreter.

No idea how this could be solved elegantly.  I guess it can't, so we
have again something to document...


Use /usr/bin/env python2? Does every python 2.x installation really contain a 
python2 executable?

I think we also would need to change some lilypond files ...

Knut


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

Re: Please test gub

2019-02-06 Thread Werner LEMBERG



> That leaves the two problems of
> 
> - LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
>   (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

This is definitely *not* a gub issue.  It's strange that only the
compilation of guile is affected by the problem, but I consider this a
pure coincidence.  IOW, this should be added to the gub documentation,
as a special preparation step for some LLVM/binutils combinations.

> - the need to make sure that `python` calls a python2 interpreter.

No idea how this could be solved elegantly.  I guess it can't, so we
have again something to document...


Werner

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

Re: Please test gub

2019-02-06 Thread Alexander Kobel


Hi Knut,

On 06.02.19 13:17, Knut Petersen wrote:

Hi Alexander!

Perfectly correct, your expectations are met. 


I hope that story of success continues ;-)


it does. :-)


Would you be so kind to test the attached patch?


Sure.

  bin/gub --fresh linux-x86::lilypond linux-64::lilypond

succeeded with your patch.

That leaves the two problems of

- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so
  (I rm'ed LLVMgold.so there for the purpose of the above gub run.)

and

- the need to make sure that `python` calls a python2 interpreter.


For the latter, the course of action is clear (but sorry, I didn't find 
the time to investigate yet), and AFAIU, the problem is entirely 
Arch-specific at the current point in time.
So the former issue apparently is more pressing, as it also emerged on 
Werner's OpenSUSE setup.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-06 Thread Federico Bruni

Il giorno mar 5 feb 2019 alle 9:20, Knut Petersen 
 ha scritto:
In case you wonder, on Arch both /lib and /lib64 are symlinked to 
/usr/lib; they also abandoned the distiction between /bin, /sbin, 
/usr/sbin and /usr/bin, and the former three are symlinked to the 
latter.

Ok, that's an important difference to other linux systems:


On Fedora there are these symlinks:

[~]$ ls -l /lib
lrwxrwxrwx 1 root root 7 13 lug 2018 /lib -> usr/lib
[~]$ ls -l /lib64
lrwxrwxrwx 1 root root 9 13 lug 2018 /lib64 -> usr/lib64
[~]$ ls -l /bin
lrwxrwxrwx 1 root root 7 13 lug 2018 /bin -> usr/bin
[~]$ ls -l /sbin
lrwxrwxrwx 1 root root 8 13 lug 2018 /sbin -> usr/sbin




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

Re: Please test gub

2019-02-06 Thread Knut Petersen


Hi Alexander!

Perfectly correct, your expectations are met. 


I hope that story of success continues ;-)

Would you be so kind to test the attached patch?

Knut
>From 9b9751b2961514a80740899e344e502d0aafd756 Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Wed, 6 Feb 2019 12:55:59 +0100
Subject: [PATCH] Test: Fix building of guile on ArchLinux

---
 gub/specs/guile.py| 10 +++---
 patches/guile-fix-build-archlinux-linux-64.patch  | 12 
 patches/guile-fix-build-archlinux-linux-x86.patch | 12 
 3 files changed, 31 insertions(+), 3 deletions(-)
 create mode 100644 patches/guile-fix-build-archlinux-linux-64.patch
 create mode 100644 patches/guile-fix-build-archlinux-linux-x86.patch

diff --git a/gub/specs/guile.py b/gub/specs/guile.py
index 61b17ec4..0e16bc71 100644
--- a/gub/specs/guile.py
+++ b/gub/specs/guile.py
@@ -166,6 +166,13 @@ class Guile__linux (Guile):
 compile_command = ('export LD_LIBRARY_PATH=%(builddir)s/libguile/.libs:%(system_prefix)s/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH};'
 + Guile.compile_command)
 
+class Guile__linux__64 (Guile__linux):
+patches = Guile.patches + ['guile-fix-build-archlinux-linux-64.patch']
+
+class Guile__linux__x86 (Guile__linux):
+patches = Guile.patches + ['guile-1.8.6-pthreads-cross.patch',
+   'guile-fix-build-archlinux-linux-x86.patch']
+
 class Guile__linux__ppc (Guile__linux):
 config_cache_overrides = Guile__linux.config_cache_overrides + '''
 guile_cv_have_libc_stack_end=no
@@ -194,9 +201,6 @@ class Guile__darwin (Guile):
'%(srcdir)s/Makefile.in')
 Guile.configure (self)
 
-class Guile__linux__x86 (Guile):
-patches = Guile.patches + ['guile-1.8.6-pthreads-cross.patch']
-
 class Guile__tools (tools.AutoBuild, Guile):
 dependencies = (Guile.dependencies
 + ['autoconf', 'automake', 'gettext', 'flex', 'libtool'])
diff --git a/patches/guile-fix-build-archlinux-linux-64.patch b/patches/guile-fix-build-archlinux-linux-64.patch
new file mode 100644
index ..481c3c25
--- /dev/null
+++ b/patches/guile-fix-build-archlinux-linux-64.patch
@@ -0,0 +1,12 @@
+diff -Naur guile-1.8.7/libguile/Makefile.in guilepatched/libguile/Makefile.in
+--- guile-1.8.7/libguile/Makefile.in	2019-02-06 11:45:33.323913617 +0100
 guilepatched/libguile/Makefile.in	2019-02-06 11:44:05.980786951 +0100
+@@ -676,7 +676,7 @@
+ 	rm -f $$list
+ guile$(EXEEXT): $(guile_OBJECTS) $(guile_DEPENDENCIES) 
+ 	@rm -f guile$(EXEEXT)
+-	$(guile_LINK) $(guile_OBJECTS) $(guile_LDADD) $(LIBS)
++	$(guile_LINK) $(guile_OBJECTS) $(guile_LDADD) $(LIBS) ../../../root/lib64/ld-linux-x86-64.so.2
+ install-binSCRIPTS: $(bin_SCRIPTS)
+ 	@$(NORMAL_INSTALL)
+ 	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
diff --git a/patches/guile-fix-build-archlinux-linux-x86.patch b/patches/guile-fix-build-archlinux-linux-x86.patch
new file mode 100644
index ..58d0d2d0
--- /dev/null
+++ b/patches/guile-fix-build-archlinux-linux-x86.patch
@@ -0,0 +1,12 @@
+diff -Naur guile-1.8.7/libguile/Makefile.in guilepatched/libguile/Makefile.in
+--- guile-1.8.7/libguile/Makefile.in	2019-02-06 11:45:33.323913617 +0100
 guilepatched/libguile/Makefile.in	2019-02-06 11:44:05.980786951 +0100
+@@ -676,7 +676,7 @@
+ 	rm -f $$list
+ guile$(EXEEXT): $(guile_OBJECTS) $(guile_DEPENDENCIES) 
+ 	@rm -f guile$(EXEEXT)
+-	$(guile_LINK) $(guile_OBJECTS) $(guile_LDADD) $(LIBS)
++	$(guile_LINK) $(guile_OBJECTS) $(guile_LDADD) $(LIBS) ../../../root/lib/ld-linux.so.2
+ install-binSCRIPTS: $(bin_SCRIPTS)
+ 	@$(NORMAL_INSTALL)
+ 	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
-- 
2.20.1

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

Re: Please test gub

2019-02-05 Thread Alexander Kobel


Hi,

On 05.02.19 09:20, Knut Petersen wrote:

Hi Alexander!


In case you wonder, on Arch both /lib and /lib64 are symlinked to 
/usr/lib; they also abandoned the distiction between /bin, /sbin, 
/usr/sbin and /usr/bin, and the former three are symlinked to the latter.



Ok, that's an important difference to other linux systems:

Could it be that

bin/gub --fresh darwin-ppc::guile darwin-x86::guile
freebsd-64::guile freebsd-x86::guile linux-ppc::guile mingw::guile
tools::guile

succeeds


It does.


and that

bin/gub --fresh linux-x86::guile
bin/gub --fresh linux-64::guile

both fail?


They do.


I think (hope) that

bin/gub --fresh darwin-ppc::lilypond darwin-x86::lilypond
freebsd-64::lilypond freebsd-x86::lilypond linux-ppc::lilypond
mingw::lilypond

should also succeed in that case ...


Perfectly correct, your expectations are met.


HTH,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-05 Thread Knut Petersen


Hi Alexander!


The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2.

Could you please execute

    ls -l `find -L /lib* /usr /home/akobel/gub | grep ld-linux-x86-64.so.2`

and mail me the result?


Sure, that'd be

lrwxrwxrwx 1 akobel akobel 11 31. Jan 17:32 
/home/akobel/gub/gub/target/linux-64/root/lib64/ld-linux-x86-64.so.2 -> 
ld-2.3.6.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib64/ld-linux-x86-64.so.2 -> 
ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib/ld-linux-x86-64.so.2 -> 
ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /usr/lib64/ld-linux-x86-64.so.2 -> 
ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /usr/lib/ld-linux-x86-64.so.2 -> 
ld-2.28.so

and /usr/lib/ld-2.28.so is part of the glibc package.

In case you wonder, on Arch both /lib and /lib64 are symlinked to /usr/lib; 
they also abandoned the distiction between /bin, /sbin, /usr/sbin and /usr/bin, 
and the former three are symlinked to the latter.


Ok, that's an important difference to other linux systems:

Could it be that

   bin/gub --fresh darwin-ppc::guile darwin-x86::guile freebsd-64::guile 
freebsd-x86::guile linux-ppc::guile mingw::guile tools::guile

succeeds and that

   bin/gub --fresh linux-x86::guile
   bin/gub --fresh linux-64::guile

both fail? I think (hope) that

   bin/gub --fresh darwin-ppc::lilypond darwin-x86::lilypond 
freebsd-64::lilypond freebsd-x86::lilypond linux-ppc::lilypond mingw::lilypond

should also succeed in that case ...

Knut


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

Re: Please test gub

2019-02-04 Thread Alexander Kobel


On 05.02.19 08:40, Knut Petersen wrote:

On 04.02.19 15:29, Alexander Kobel wrote:

Remote debugging... Perfectly correct, here you are.


Thanks.

The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2.


Could you please execute

ls -l `find -L /lib* /usr /home/akobel/gub | grep ld-linux-x86-64.so.2`

and mail me the result?


Sure, that'd be

lrwxrwxrwx 1 akobel akobel 11 31. Jan 17:32 
/home/akobel/gub/gub/target/linux-64/root/lib64/ld-linux-x86-64.so.2 -> 
ld-2.3.6.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib64/ld-linux-x86-64.so.2 
-> ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 /lib/ld-linux-x86-64.so.2 -> 
ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 
/usr/lib64/ld-linux-x86-64.so.2 -> ld-2.28.so
lrwxrwxrwx 1 root   root   10 11. Okt 10:18 
/usr/lib/ld-linux-x86-64.so.2 -> ld-2.28.so


and /usr/lib/ld-2.28.so is part of the glibc package.

In case you wonder, on Arch both /lib and /lib64 are symlinked to 
/usr/lib; they also abandoned the distiction between /bin, /sbin, 
/usr/sbin and /usr/bin, and the former three are symlinked to the latter.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-04 Thread Knut Petersen


On 04.02.19 15:29, Alexander Kobel wrote:

Remote debugging... Perfectly correct, here you are.


Thanks.

The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2.

Could you please execute

   ls -l `find -L /lib* /usr /home/akobel/gub | grep ld-linux-x86-64.so.2`

and mail me the result?

Knut


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

Re: Please test gub

2019-02-04 Thread Knut Petersen


Hi Alexander!



The argumens given are ok. As usual

    mkdir -p STRACE
    strace -v -f -ff -s 1 -o STRACE/TP bin/gub --fresh linux-64::guile

will help to identify the problem.


hm, that gives appx. 2 GB of traces, and I'm not sure which process' trace I 
should look at. Nothing segfaults, so I don't get a PID hint as for the 
previous problem.

Appx. 380 MB worth of traces contain the buzzwords out_of_memory; those 
compress to 4.6 MB, so I could send them off-list?


In your log I read:

/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined reference 
to `_dl_out_of_memory@GLIBC_PRIVATE'.

As ld announces problems to stderr

   grep _dl_out_of_memory@GLIBC_PRIVATE STRACE/* | grep 'write(2,'

will probably give exactly one match ... gub is writing to a file with fd!=2 
and collect2 should only read ...

With STRACE/TP. changed to the match

   grep '^execve' STRACE/TP. | grep -o '^[^,]*'

should result in

   
execve("/home/akobel/gub/gub/target/linux-64/root/usr/cross/bin/x86_64-linux-ld"

Please send that one file STRACE/TP. that's enough ;-)

Knut

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

Re: Please test gub

2019-02-04 Thread Alexander Kobel


Hi,

On 02.02.19 10:27, Knut Petersen wrote:

On 01.02.19 15:06, Alexander Kobel wrote:

On 01.02.19 14:51, Alexander Kobel wrote:

GUB-bing further down the road now...


Hrmpf, back here sooner than I hoped.
Guile barfed - see the attached log.

libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o 
.libs/guile guile-guile.o  ./.libs/libguile.so 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libgmp.so -lcrypt 
-lm /home/akobel/gub/gub/target/linux-64/root/usr/lib/libltdl.so -ldl 
-Wl,-rpath -Wl,/usr/lib -Wl,-rpath 
-Wl,/home/akobel/gub/gub/target/linux-64/root/usr/lib
/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined 
reference to `_dl_out_of_memory@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status 


The argumens given are ok. As usual

mkdir -p STRACE
strace -v -f -ff -s 1 -o STRACE/TP bin/gub --fresh linux-64::guile

will help to identify the problem.


hm, that gives appx. 2 GB of traces, and I'm not sure which process' 
trace I should look at. Nothing segfaults, so I don't get a PID hint as 
for the previous problem.


Appx. 380 MB worth of traces contain the buzzwords out_of_memory; those 
compress to 4.6 MB, so I could send them off-list?



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-02 Thread Knut Petersen


On 01.02.19 15:06, Alexander Kobel wrote:

On 01.02.19 14:51, Alexander Kobel wrote:

GUB-bing further down the road now...


Hrmpf, back here sooner than I hoped.
Guile barfed - see the attached log.

libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o .libs/guile guile-guile.o  ./.libs/libguile.so /home/akobel/gub/gub/target/linux-64/root/usr/lib/libgmp.so -lcrypt -lm /home/akobel/gub/gub/target/linux-64/root/usr/lib/libltdl.so -ldl -Wl,-rpath -Wl,/usr/lib -Wl,-rpath 
-Wl,/home/akobel/gub/gub/target/linux-64/root/usr/lib

/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined reference 
to `_dl_out_of_memory@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status 


The argumens given are ok. As usual

   mkdir -p STRACE
   strace -v -f -ff -s 1 -o STRACE/TP bin/gub --fresh linux-64::guile

will help to identify the problem.

Knut

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

Re: Please test gub


On 01.02.19 14:51, Alexander Kobel wrote:

GUB-bing further down the road now...


Hrmpf, back here sooner than I hoped.
Guile barfed - see the attached log.

libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o 
.libs/guile guile-guile.o  ./.libs/libguile.so 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libgmp.so -lcrypt -lm 
/home/akobel/gub/gub/target/linux-64/root/usr/lib/libltdl.so -ldl 
-Wl,-rpath -Wl,/usr/lib -Wl,-rpath 
-Wl,/home/akobel/gub/gub/target/linux-64/root/usr/lib
/home/akobel/gub/gub/target/linux-64/root/lib64/libc.so.6: undefined 
reference to `_dl_out_of_memory@GLIBC_PRIVATE'

collect2: error: ld returned 1 exit status


Cheers,
Alex


guile.log.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub


On 01.02.19 14:28, Knut Petersen wrote:
I wonder if we really need libopenjpeg ...  Yes, we need jpeg ... but  
we also link against our own libjpeg, and we talk about tools::poppler.


Note: libopenjpeg is (misnomed and) only required for JPEG 2000. 
Traditional JPEG is taken care of by libjpeg, which doesn't cause problems.



You could try to build with:

commit 751ac35d67764c9be22a887ad513b819d8ed101d (HEAD -> newStateOfArt)
[...]


Almost.

diff --git a/gub/specs/poppler.py b/gub/specs/poppler.py
index d8381f68..c8ec7063 100644
--- a/gub/specs/poppler.py
+++ b/gub/specs/poppler.py
@@ -11,8 +11,9 @@ class Poppler (target.AutoBuild):
 'libxml2-devel',
 ]
 configure_flags = (target.AutoBuild.configure_flags
-+ ' --disable-poppler-qt'
++ ' --disable-libopenjpeg'
 + ' --disable-poppler-qt4'
++ ' --disable-poppler-qt5'
 + ' --enable-xpdf-headers'
 + ' --disable-gtk-test')
 # FIXME: poppler, librsvg, cairo, gtk dependencies?
@@ -43,7 +44,8 @@ class Poppler__tools (tools.AutoBuild, Poppler):
 'libxml2',
 ]
 configure_flags = (tools.AutoBuild.configure_flags
-   + ' --disable-poppler-qt'
+   + ' --disable-libopenjpeg'
+ ' --disable-poppler-qt4'
+   + ' --disable-poppler-qt5'
+ ' --enable-xpdf-headers'
+ ' --disable-gtk-test')

did the job.

Note the 'lib' in ' --disable-libopenjpeg', and that I added it to 
Poppler__tools as well (just in case).
Also, '--disable-poppler-qt' is reportedly unknown, and should end with 
a '5' instead.

Finally, some solace from configure:

"Warning: Using libopenjpeg is recommended. The internal JPX decoder is 
unmaintained."


Which probably means that there's no loss in functionality, as the 
decoder at least used to work.



GUB-bing further down the road now...


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-01 Thread Knut Petersen


On 01.02.19 14:09, Alexander Kobel wrote:

is there an libopenjpeg1-devel package installed? If not: try to install and 
rerun gub ...


yes and no - Arch follows the principle that the packages provide both runtimes 
and development requirements at the same time, so there is no separation as in, 
e.g., Debian.
In particular, I have the headers on my system, and pkg-config is configured 
correctly:



I wonder if we really need libopenjpeg ...  Yes, we need jpeg ... but  we also 
link against our own libjpeg, and we talk about tools::poppler.

You could try to build with:

commit 751ac35d67764c9be22a887ad513b819d8ed101d (HEAD -> newStateOfArt)
Author: Knut Petersen 
Date:   Fri Feb 1 14:15:48 2019 +0100

    TEST: Do we really need libopenjpeg in tools::poppler?

diff --git a/gub/specs/poppler.py b/gub/specs/poppler.py
index d8381f68..dcd44eef 100644
--- a/gub/specs/poppler.py
+++ b/gub/specs/poppler.py
@@ -43,6 +43,7 @@ class Poppler__tools (tools.AutoBuild, Poppler):
 'libxml2',
 ]
 configure_flags = (tools.AutoBuild.configure_flags
+   + ' --disable-libopenjpeg'
    + ' --disable-poppler-qt'
    + ' --disable-poppler-qt4'
    + ' --enable-xpdf-headers'

Knut


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

Re: Please test gub


On 01.02.19 14:09, Alexander Kobel wrote:

Hi,

On 01.02.19 13:51, Knut Petersen wrote:

On 31.01.19 16:04, Alexander Kobel wrote:



and I can cleanly compile the recent poppler 0.73 with openjpeg2 
backend from source, with a simple cmake + make.



is there an libopenjpeg1-devel package installed? If not: try to 
install and rerun gub ...


yes and no - Arch follows the principle that the packages provide both 
runtimes and development requirements at the same time, so there is no 
separation as in, e.g., Debian.
In particular, I have the headers on my system, and pkg-config is 
configured correctly:


Moreover, checking with poppler 0.49 as used in GUB, and loosely 
following the package build script for 0.49 from



https://git.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/poppler=1626dc8989ffc95eab611e4bd47d54f9b0fcfde0

(nothing too fancy in Arch packaging, yay!), the build succeeds after

  ./configure <--enable-unrelated-stuff> --enable-libopenjpeg=openjpeg1
  make

Note the absence of any paths, flags, etc. - everything is detected 
automagically:


Building poppler with support for:
  font configuration:  fontconfig
  splash output:   yes
  cairo output:yes
  qt4 wrapper: yes
  qt5 wrapper: yes
  glib wrapper:yes
introspection: yes
  cpp wrapper: yes
  use gtk-doc: no
  use libjpeg: yes
  use libpng:  yes
  use libtiff: yes
  use zlib compress:   yes
  use zlib uncompress: no
  use nss: yes
  use libcurl: no
  use libopenjpeg: yes
  with openjpeg1
  use cms: yes
  with lcms2
  command line utils:  yes


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub


Hi,

On 01.02.19 13:51, Knut Petersen wrote:

On 31.01.19 16:04, Alexander Kobel wrote:



and I can cleanly compile the recent poppler 0.73 with openjpeg2 
backend from source, with a simple cmake + make.



is there an libopenjpeg1-devel package installed? If not: try to install 
and rerun gub ...


yes and no - Arch follows the principle that the packages provide both 
runtimes and development requirements at the same time, so there is no 
separation as in, e.g., Debian.
In particular, I have the headers on my system, and pkg-config is 
configured correctly:


% ls -1 /usr/include/openjpeg-*/*
/usr/include/openjpeg-1.5/openjpeg.h
/usr/include/openjpeg-2.3/openjpeg.h
/usr/include/openjpeg-2.3/opj_config.h
/usr/include/openjpeg-2.3/opj_stdint.h

% pkg-config --cflags --libs libopenjpeg 


-I/usr/include/openjpeg-1.5 -lopenjpeg

% pkg-config --cflags --libs libopenjpeg1
-I/usr/include/openjpeg-1.5 -lopenjpeg

% pkg-config --cflags --libs libopenjp2
-I/usr/include/openjpeg-2.3 -lopenjp2


Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-02-01 Thread Knut Petersen


On 31.01.19 16:04, Alexander Kobel wrote:



and I can cleanly compile the recent poppler 0.73 with openjpeg2 backend from 
source, with a simple cmake + make.



is there an libopenjpeg1-devel package installed? If not: try to install and 
rerun gub ...

Knut

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

Re: Please test gub

2019-02-01 Thread Knut Petersen


On 31.01.19 15:43, Alexander Kobel wrote:

Addendum:

On 31.01.19 15:39, Alexander Kobel wrote:

Whenever I can, I "correct" shebangs to python2 (without ever having looked up 
this PEP), and nobody ever complained that it breaks their workflow.


That is to say: I've yet to encounter a system where python points to python2.x, but at the 
same time there's no python2 -> python2.x symlink/hardlink/anylink/copy/wrapper. So I 
doubt that adding the "2" will cause any grief.


There are not too many files with a python  shebang ...

   LANG=c grep -r '^#!' * | grep -v '^Binary file' | grep -v uploads/ | grep -v 
downloads/ | grep -v target | grep -i python
   bin/cygwin-packager:#! /usr/bin/env python
   bin/gub-tester:#! /usr/bin/env python
   bin/build-architecture:#! /usr/bin/env python
   bin/build-platform:#! /usr/bin/env python
   bin/gib:#! /usr/bin/env python
   bin/gupdate:#! /usr/bin/env python
   bin/gub:#! /usr/bin/env python
   bin/gpkg:#! /usr/bin/env python
   gub/runner.py:#! /usr/bin/env python
   gub/distcc.py:#!/usr/bin/env python
   gub/with-lock.py:#!/usr/bin/env python
   gub/versiondb.py:#!/usr/bin/env python
   sourcefiles/pytt.py:#! @PYTHON@
   sourcefiles/python-config.py:#! @PYTHON_FOR_BUILD@
   test-lily/rsync-lily-doc.py:#! /usr/bin/env python
   test-lily/test-binary.py:#! /usr/bin/env python
   test-lily/rsync-test.py:#! /usr/bin/env python
   test-lily/upload.py:#! /usr/bin/env python
   test-lily/dist-check.py:#! /usr/bin/env python
   test-lily/cron-builder.py:#! /usr/bin/env python

Do you want to prepare a patch?

Knut

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

Re: Please test gub


On 31.01.19 16:15, Karlin High wrote:

On 1/31/2019 9:04 AM, Alexander Kobel wrote:

BTW, can we actually add images in Lily?


Encapsulated PostScript images are fair game with \epsfile



I know I used that once, but I forget which program I used to make the 
EPS file containing the image. Perhaps it was GIMP.


Ah, of course. There's jpeg2ps (from CTAN) which IIRC wraps JPEG without 
recompression to ps or eps files; for anything else, I'd probably go for 
pdfjam or img2pdf, followed by pdftops -eps, or just ImageMagick's (or 
GraphicsMagick's) convert.
GIMP can do it, too, but I doubt you can specify the compression 
algorithm (in particular, choose between lossless and lossy, the latter 
possibly without recompression).


But in fact I'm fairly happy to leave PostScript behind the scenes, only 
touch PDF, and not to worry too much when buying printers... ;-)



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-01-31 Thread Karlin High


On 1/31/2019 9:04 AM, Alexander Kobel wrote:

BTW, can we actually add images in Lily?


Encapsulated PostScript images are fair game with \epsfile



I know I used that once, but I forget which program I used to make the 
EPS file containing the image. Perhaps it was GIMP.

--
Karlin High
Missouri, USA

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

Re: Please test gub


Hi,

On 31.01.19 13:25, Alexander Kobel wrote:

Indeed, LLVMgold.so pops up in the trace.
On my system, the symlink for liblto_plugin.so already exists, so I only 
had to remove (rename wasn't enough) LLVMgold.so.


Building tools::guile succeeds after that modification; I'll test the 
further progress of `make lilypond` later.


The build went on cleanly until poppler 0.49, which apparently is clever 
enough to figure out that it can't deal with my openjpeg installation ...


checking for LIBOPENJPEG... no
checking for opj_cio_open in -lopenjpeg... yes
checking openjpeg.h usability... no
checking openjpeg.h presence... no
checking for openjpeg.h... no

... but nevertheless insists on using it ...

Building poppler with support for:
  [...]
  use libopenjpeg: yes
  with openjpeg1
  [...]

... and, to no surprise, fails:

/home/akobel/gub/gub/target/tools/src/poppler-0.49.0/poppler/JPEG2000Stream.cc:20:10: 
fatal error: openjpeg.h: No such

 file or directory
 #include 
  ^~~~
compilation terminated.


FWIW, both openjpeg 1 and 2 are installed system-wide:

extra/openjpeg2 2.3.0-3 [installed]
An open source JPEG 2000 codec, version 2.3.0
extra/openjpeg 1.5.2-2 [installed]
An open source JPEG 2000 codec

and I can cleanly compile the recent poppler 0.73 with openjpeg2 backend 
from source, with a simple cmake + make.



Perhaps it's wise to disable openjpeg entirely for poppler within GUB? 
Note that, despite the name, openjpeg is only a concern for JPEG2000; 
plain old JPEG is supported by libjpeg. (BTW, can we actually add images 
in Lily?)



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub


Addendum:

On 31.01.19 15:39, Alexander Kobel wrote:
Whenever I can, I "correct" shebangs to python2 (without ever having 
looked up this PEP), and nobody ever complained that it breaks their 
workflow.


That is to say: I've yet to encounter a system where python points to 
python2.x, but at the same time there's no python2 -> python2.x 
symlink/hardlink/anylink/copy/wrapper. So I doubt that adding the "2" 
will cause any grief.




smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub


Hi,

On 31.01.19 15:21, David Kastrup wrote:

Knut Petersen  writes:


On 31.01.19 08:43, Alexander Kobel wrote:

Hi,

fails on Arch Linux (up-to-date, Intel Core i5-3317U).

First, all Python scripts seem to require Python2 (but python ->
python3 is the default on Arch).


I don't think that matches Python's own recommendation.  Has this
changed?


Kind of, yes, but then again, no, not really, it turns out. Lucky 
buzzwords for Google gave me PEP 394:

  https://www.python.org/dev/peps/pep-0394/

Relevant is the abstract, which in fact mentions that Arch, 
specifically, switched "early", broke the former practice (and, 
apparently, implicit and unwritten recommendation) and thus raised the 
discussion that led to PEP 394. It also says that "for the time being, 
all distributions should ensure that python, if installed, refers to the 
same target as python2, unless [...]".


*Also* relevant *now*, however, are the following point(s) from the 
recommendation:


"In order to tolerate differences across platforms, all new code that 
needs to invoke the Python interpreter should not specify python, but 
rather should specify either python2 or python3 (or the more specific 
python2.x and python3.x versions; see the Migration Notes). This 
distinction should be made in shebangs, when invoking from a shell 
script, when invoking via the system() call, or when invoking in any 
other context."


and

"In order to tolerate differences across platforms, all new code that 
needs to invoke the Python interpreter should not specify python, but 
rather should specify either python2 or python3 (or the more specific 
python2.x and python3.x versions; see the Migration Notes). This 
distinction should be made in shebangs, when invoking from a shell 
script, when invoking via the system() call, or when invoking in any 
other context."



I second the recommendation: as a happy year-long Archer, python 
shebangs are, by far, the number 1 of annoyances I encounter regularly. 
Whenever I can, I "correct" shebangs to python2 (without ever having 
looked up this PEP), and nobody ever complained that it breaks their 
workflow.
On the other hand, I still occasionally use systems with Python2 <2.7 
(strictly less than). Hence, I'd refrain from specifying a minor version 
if it can be avoided. AFAIK, 2.8 is promised to never appear, so it 
shouldn't matter for 2.x. And I don't have 3.y for y < 7 available on my 
system; yet, 3.3 scripts run perfectly albeit the author might not have 
thought about that version when writing the script.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-01-31 Thread David Kastrup

Knut Petersen  writes:

> On 31.01.19 08:43, Alexander Kobel wrote:
>> Hi,
>>
>> fails on Arch Linux (up-to-date, Intel Core i5-3317U).
>>
>> First, all Python scripts seem to require Python2 (but python ->
>> python3 is the default on Arch).

I don't think that matches Python's own recommendation.  Has this
changed?

-- 
David Kastrup

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

Re: Please test gub

2019-01-31 Thread Werner LEMBERG



> On my system, the symlink for liblto_plugin.so already exists, so I
> only had to remove (rename wasn't enough) LLVMgold.so.
> 
> Building tools::guile succeeds after that modification; [...]

OK!  BTW, It took me some weeks to identify this very problem...

> # pacman -Qo /usr/lib/bfd-plugins/{LLVMgold.so,liblto_plugin.so}
> /usr/lib/bfd-plugins/LLVMgold.so is owned by llvm-libs 7.0.1-2
> /usr/lib/bfd-plugins/liblto_plugin.so is owned by gcc 8.2.1+20181127-1
> 
> So probably deinstalling llvm-libs (and clang, and some other packages
> that depend on it) might help... :-/

Well, `ar' uses the plugins to be able to handle more binary formats;
for daily use it's not necessary to have it.

> BTW, since gcc7 was mentioned couple of times in this thread:
> /usr/lib/bfd-plugins/liblto_plugin.so points to
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/liblto_plugin.so, but I also
> have the gcc7-libs variant under
> /usr/lib/gcc/x86_64-pc-linux-gnu/7.4.1/liblto_plugin.so; but the
> build succeeded with gcc8's liblto_plugin.so, so I did not test
> that.

For `ar', the actual version of gcc doesn't matter; you can always
link to the most recent version of `liblto_plugin.so', according to
the `ar' or `gcc' documentation (right now I don't remember which
one).


Werner

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

Re: Please test gub


Hi,

strace according to Knut's instructions is attached.

On 31.01.19 12:54, Werner LEMBERG wrote:



Apart from that minor buzz, `make lilypond` does a good chunk of work,
but fails building tools::guile; log attached.


I see. libtools segfauls.



../libtool: line 950: 23645 Segmentation fault  (core dumped)
ar cru .libs/libguile.a [...]


This is probably the same bug I've encountered on my openSUSE box.
Try to remove the file (or link) `/usr/lib/bfd-plugins/LLVMgold.so'
and replace it with the gcc variant `liblto_plugin.so'.  On my system
I had to do

   cd /usr/lib/bfd-plugins
   ln -s /usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so .


Indeed, LLVMgold.so pops up in the trace.
On my system, the symlink for liblto_plugin.so already exists, so I only 
had to remove (rename wasn't enough) LLVMgold.so.


Building tools::guile succeeds after that modification; I'll test the 
further progress of `make lilypond` later.



FWIW:

# pacman -Qo /usr/lib/bfd-plugins/{LLVMgold.so,liblto_plugin.so}
/usr/lib/bfd-plugins/LLVMgold.so is owned by llvm-libs 7.0.1-2
/usr/lib/bfd-plugins/liblto_plugin.so is owned by gcc 8.2.1+20181127-1

So probably deinstalling llvm-libs (and clang, and some other packages 
that depend on it) might help... :-/


BTW, since gcc7 was mentioned couple of times in this thread:
/usr/lib/bfd-plugins/liblto_plugin.so points to 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/liblto_plugin.so, but I also have 
the gcc7-libs variant under 
/usr/lib/gcc/x86_64-pc-linux-gnu/7.4.1/liblto_plugin.so; but the build 
succeeded with gcc8's liblto_plugin.so, so I did not test that.



I don't quite get why (IIUC, which I might not) gub apparently builds 
gcc, but then seems to use the system-wide gcc down the road?



Cheers,
Alex


TP.21085.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-01-31 Thread Werner LEMBERG

>>../libtool: line 950: 23645 Segmentation fault  (core dumped)
>>ar cru .libs/libguile.a [...]
> 
> This is probably the same bug I've encountered on my openSUSE box.
> Try to remove the file (or link) `/usr/lib/bfd-plugins/LLVMgold.so'
> and replace it with the gcc variant `liblto_plugin.so'.  On my
> system I had to do
> 
>   cd /usr/lib/bfd-plugins
>   ln -s /usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so .

Just for completeness: This bug is not related to gub.

References:

  https://sourceware.org/bugzilla/show_bug.cgi?id=23928
  https://bugzilla.opensuse.org/show_bug.cgi?id=1117239

In case you can reproduce the bug on your platform please say so in
the report :-)


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

Re: Please test gub

2019-01-31 Thread Werner LEMBERG


>> Apart from that minor buzz, `make lilypond` does a good chunk of work,
>> but fails building tools::guile; log attached.
> 
> I see. libtools segfauls.

>../libtool: line 950: 23645 Segmentation fault  (core dumped)
>ar cru .libs/libguile.a [...]

This is probably the same bug I've encountered on my openSUSE box.
Try to remove the file (or link) `/usr/lib/bfd-plugins/LLVMgold.so'
and replace it with the gcc variant `liblto_plugin.so'.  On my system
I had to do

  cd /usr/lib/bfd-plugins
  ln -s /usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so .


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

Re: Please test gub

2019-01-31 Thread Knut Petersen


On 31.01.19 08:43, Alexander Kobel wrote:

Hi,

fails on Arch Linux (up-to-date, Intel Core i5-3317U).

First, all Python scripts seem to require Python2 (but python -> python3 is the default on Arch). I placed a symlink to python -> python2 in a high-priority $PATH as a workaround, but it might be a good idea to replace the shebang line by ".../env python2" for scripts which are not 
Python3-compatible.


thanks for the info ... the python-> python2 symlink should be a valid workaround 
for the moment. Probably also a python-config -> python2-config symlink is needed 
later ...



Apart from that minor buzz, `make lilypond` does a good chunk of work, but 
fails building tools::guile; log attached.


I see. libtools segfauls.

   libtool: link: ar cru .libs/libguile.a  libguile_la-alist.o 
libguile_la-arbiters.o libguile_la-async.o libguile_la-backtrace.o 
libguile_la-boolean.o libguile_la-chars.o libguile_la-continuations.o 
libguile_la-convert.o libguile_la-debug.o libguile_la-deprecation.o 
libguile_la-deprecated.o
   libguile_la-discouraged.o libguile_la-dynwind.o libguile_la-environments.o 
libguile_la-eq.o libguile_la-error.o libguile_la-eval.o libguile_la-evalext.o 
libguile_la-extensions.o libguile_la-feature.o libguile_la-fluids.o 
libguile_la-fports.o libguile_la-futures.o libguile_la-gc.o
   libguile_la-gc-mark.o libguile_la-gc-segment.o libguile_la-gc-malloc.o 
libguile_la-gc-card.o libguile_la-gc-freelist.o libguile_la-gc_os_dep.o 
libguile_la-gdbint.o libguile_la-gh_data.o libguile_la-gh_eval.o 
libguile_la-gh_funcs.o libguile_la-gh_init.o libguile_la-gh_io.o 
libguile_la-gh_list.o
   libguile_la-gh_predicates.o libguile_la-goops.o libguile_la-gsubr.o 
libguile_la-guardians.o libguile_la-hash.o libguile_la-hashtab.o 
libguile_la-hooks.o libguile_la-i18n.o libguile_la-init.o libguile_la-inline.o 
libguile_la-ioext.o libguile_la-keywords.o libguile_la-lang.o libguile_la-list.o
   libguile_la-load.o libguile_la-macros.o libguile_la-mallocs.o 
libguile_la-modules.o libguile_la-numbers.o libguile_la-objects.o 
libguile_la-objprop.o libguile_la-options.o libguile_la-pairs.o 
libguile_la-ports.o libguile_la-print.o libguile_la-procprop.o 
libguile_la-procs.o
   libguile_la-properties.o libguile_la-random.o libguile_la-rdelim.o 
libguile_la-read.o libguile_la-root.o libguile_la-rw.o libguile_la-scmsigs.o 
libguile_la-script.o libguile_la-simpos.o libguile_la-smob.o libguile_la-sort.o 
libguile_la-srcprop.o libguile_la-stackchk.o libguile_la-stacks.o
   libguile_la-stime.o libguile_la-strings.o libguile_la-srfi-4.o 
libguile_la-srfi-13.o libguile_la-srfi-14.o libguile_la-strorder.o 
libguile_la-strports.o libguile_la-struct.o libguile_la-symbols.o 
libguile_la-threads.o libguile_la-null-threads.o libguile_la-throw.o 
libguile_la-values.o
   libguile_la-variable.o libguile_la-vectors.o libguile_la-version.o 
libguile_la-vports.o libguile_la-weaks.o libguile_la-ramap.o libguile_la-unif.o 
dynl.o filesys.o posix.o net_db.o socket.o regex-posix.o
   ar: /home/akobel/gub/gub/target/tools/root/usr/lib/libz.so.1: no version 
information available (required by /usr/lib/libbfd-2.31.1.so)
   ar: `u' modifier ignored since `D' is the default (see `U')
   ar: /usr/lib/../lib/libxml2.so.2: symbol gzopen64 version ZLIB_1.2.3.3 not 
defined in file libz.so.1 with link time reference

   ../libtool: line 950: 23645 Segmentation fault  (core dumped) ar cru 
.libs/libguile.a libguile_la-alist.o libguile_la-arbiters.o libguile_la-async.o 
libguile_la-backtrace.o libguile_la-boolean.o libguile_la-chars.o 
libguile_la-continuations.o libguile_la-convert.o libguile_la-debug.o
   libguile_la-deprecation.o libguile_la-deprecated.o libguile_la-discouraged.o 
libguile_la-dynwind.o libguile_la-environments.o libguile_la-eq.o 
libguile_la-error.o libguile_la-eval.o libguile_la-evalext.o 
libguile_la-extensions.o libguile_la-feature.o libguile_la-fluids.o 
libguile_la-fports.o
   libguile_la-futures.o libguile_la-gc.o libguile_la-gc-mark.o 
libguile_la-gc-segment.o libguile_la-gc-malloc.o libguile_la-gc-card.o 
libguile_la-gc-freelist.o libguile_la-gc_os_dep.o libguile_la-gdbint.o 
libguile_la-gh_data.o libguile_la-gh_eval.o libguile_la-gh_funcs.o 
libguile_la-gh_init.o
   libguile_la-gh_io.o libguile_la-gh_list.o libguile_la-gh_predicates.o 
libguile_la-goops.o libguile_la-gsubr.o libguile_la-guardians.o 
libguile_la-hash.o libguile_la-hashtab.o libguile_la-hooks.o libguile_la-i18n.o 
libguile_la-init.o libguile_la-inline.o libguile_la-ioext.o 
libguile_la-keywords.o
   libguile_la-lang.o libguile_la-list.o libguile_la-load.o 
libguile_la-macros.o libguile_la-mallocs.o libguile_la-modules.o 
libguile_la-numbers.o libguile_la-objects.o libguile_la-objprop.o 
libguile_la-options.o libguile_la-pairs.o libguile_la-ports.o 
libguile_la-print.o libguile_la-procprop.o
   libguile_la-procs.o libguile_la-properties.o libguile_la-random.o 
libguile_la-rdelim.o libguile_la-read.o libguile_la-root.o libguile_la-rw.o

Re: Please test gub

2019-01-30 Thread Alexander Kobel


Hi,

fails on Arch Linux (up-to-date, Intel Core i5-3317U).

First, all Python scripts seem to require Python2 (but python -> python3 
is the default on Arch). I placed a symlink to python -> python2 in a 
high-priority $PATH as a workaround, but it might be a good idea to 
replace the shebang line by ".../env python2" for scripts which are not 
Python3-compatible.



Apart from that minor buzz, `make lilypond` does a good chunk of work, 
but fails building tools::guile; log attached.


FWIW, the gcc7 and gcc7-libs packages from the upstream repo (7.4.1) are 
installed (as well as the up-to-date gcc and gcc-libs 8.2.1), as well as 
all build and runtime dependencies for Lilypond on this architecture. At 
least, I successfully built 2.19.something from Git clones on this machine.
As far as I can remember, such a "standalone arch-specific" build of 
Lilypond doesn't compile guile, but relies on the guile1.8 package from 
the repos (the package maintainers don't seem to require any special 
precautions for building it, as can be seen in the packaging script at 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/guile1.8).
Notable difference here: GUB tries to work with Guile 1.8.7, upstream is 
at 1.8.8.



The only other part of the log that caught my eye:

building package: linux-x86::cross/gcc-core
 *** [...]
 *** Stage: pkg_install (cross/gcc-core, linux-x86)

building package: linux-x86::glibc-core
 *** [...]
 *** Stage: pkg_install (glibc-core, linux-x86)

building package: linux-x86::cross/gcc
 *** [...]
 *** Stage: pkg_install (cross/gcc, linux-x86)
  cross/gcc-core conflicts with cross/gcc-doc
removing cross/gcc-core


Not sure whether that's intended; is gcc-core just required to build gcc 
and supposed to be replaced after that?



Cheers,
Alex


On 28.01.19 13:53, Knut Petersen wrote:

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

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


guile.log.xz
Description: application/xz


smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

2019-01-30 Thread Urs Liska



Am 30.01.19 um 12:14 schrieb Knut Petersen:

Hi everybody!

Thanks for testing.

Here is a summary of the current status:

   openSuSE Tumbleweed: Gub succeeds, but it is necessary to install 
gcc-7.

   openSuSE Leaf 42.3:  Gub succeeds.
   Ubuntu 18.04[.1]:    Gub succeeds. But. libc6-dev-i386 must be 
installed.
     If you installed libn32curses5 and lib32z1 
you don't need to install libc6-dev-i386 explicitly.
     Also builds inside VirtualBox 5.2.22r126460 
on Windows 7 Pro 64-bit SP1
   Ubuntu 16.04:    Gub succeeds on my system, but it fails on the 
system of Federico Bruni. Don't know why,

   Ubuntu 14.04:    Gub succeeds.
   Linux Mint 19.1: Gub succeeds.
   Fedora 29:   Seems to be broken. Needs a downgrade to 
gcc-7, but that's not enough. [Federico Bruni]

   Debina 9:    Seems to be broken. [Federico Bruni]

As mentioned I *did* successfully run GUB on Debian 9.7, after adding 
either libc6-dev-i386 or libn32curses5 and lib32z1 (both approaches worked).


Urs


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

Re: Please test gub

2019-01-30 Thread Knut Petersen


Hi everybody!

Thanks for testing.

Here is a summary of the current status:

   openSuSE Tumbleweed: Gub succeeds, but it is necessary to install gcc-7.
   openSuSE Leaf 42.3:  Gub succeeds.
   Ubuntu 18.04[.1]:    Gub succeeds. But. libc6-dev-i386 must be installed.
 If you installed libn32curses5 and lib32z1 you don't 
need to install libc6-dev-i386 explicitly.
 Also builds inside VirtualBox 5.2.22r126460 on Windows 
7 Pro 64-bit SP1
   Ubuntu 16.04:    Gub succeeds on my system, but it fails on the system 
of Federico Bruni. Don't know why,
   Ubuntu 14.04:    Gub succeeds.
   Linux Mint 19.1: Gub succeeds.
   Fedora 29:   Seems to be broken. Needs a downgrade to gcc-7, but 
that's not enough. [Federico Bruni]
   Debina 9:    Seems to be broken. [Federico Bruni]


Some remarks to the original test instructions:


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.



Important: Gub needs 32-bit C deveopment support even if we build on a 64-bit 
machine with a 64-bit os. On ubuntu 18.04 you need libc6-dev-i386. On other 
systems there will be similar packages.


Important: We are incompatible to gcc-8. Downgrade to or install gcc-7.


Q: Gub stopped. How can I see that gub succeeded?

A: 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.

Knut

___
lilypond-devel mailing list
lilypond-devel@gnu.org

Re: Please test gub

2019-01-30 Thread Knut Petersen


On 30.01.19 10:46, Werner LEMBERG wrote:

[...] getting identical checksums *for the doc bundle* is probably
only possible if you have a gub installation containing a TeXLive
package also.

As time stamps are stored e.g. in pdf files we won't get constant
checksums unless we do some special postprocessing.

This is no longer true, fortunately, since all major TeX engines
support the `SOURCE_DATE_EPOCH' environment variable, cf.

   
https://tex.stackexchange.com/questions/229605/reproducible-latex-builds-compile-to-a-file-which-always-hashes-to-the-same-va

However, there might be subtle differences in the used LaTeX packages
that can only be fixed if the packages are *identical* in all gub
installations, which in turn implies that you need TeXLive as a gub package


[ I forgot to cc lilypond-dev in my original reply ...]

Remember that we do not release the documents generated by *TeX, we feed those 
documents to ghostscript and relase the results.

There was a related discussion on ghostscripts bugzilla:

https://bugs.ghostscript.com/show_bug.cgi?id=696765

Knut

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

Re: Please test gub



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

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

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

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 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: 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

Re: Please test gub


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




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


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: Please test gub







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

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


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 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

Re: Please test gub


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


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