Re: GUB failure

[Jonas Hahnfeld]

Am Dienstag, den 07.04.2020, 10:36 +0100 schrieb Phil Holmes:
> If I type python-gdbm at the terminal I get "command not found".  a) is this 
> the right way to check?  b) I'd appreciate guidance on how best to install 
> it if I don't have it.

It's a packet, not a command. The usual
 $ apt-get install python-gdbm
should do.

Jonas


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

Re: GUB failure

[Phil Holmes]

If I type python-gdbm at the terminal I get "command not found".  a) is this 
the right way to check?  b) I'd appreciate guidance on how best to install 
it if I don't have it.


Thanks.

--
Phil Holmes


- Original Message - 
From: "Jonas Hahnfeld" 

To: "Phil Holmes" 
Cc: "David Kastrup" ; "Devel" 
Sent: Tuesday, April 07, 2020 10:25 AM
Subject: Re: GUB failure

Re: GUB failure

[Jonas Hahnfeld]

Am Dienstag, den 07.04.2020, 10:20 +0100 schrieb Phil Holmes:
> - Original Message - 
> From: "Phil Holmes" <
> m...@philholmes.net
> >
> To: "Thomas Morley" <
> thomasmorle...@gmail.com
> >
> Cc: "David Kastrup" <
> d...@gnu.org
> >; "Devel" <
> lilypond-devel@gnu.org
> >
> Sent: Monday, April 06, 2020 5:02 PM
> Subject: Re: GUB failure
> 
> 
> > I bit the bullet and started the upgrade to 16.04.  I check that's OK then 
> > consider 18.04 later.  Upgrading via the GUI software updater.
> > 
> 
> Now with Ubuntu 16.04 and therefore Python 3.5, the build failed.  Any help 
> appreciated.  Error was:
> 
> Traceback (most recent call last):
> File "bin/gub", line 231, in exceptional_build
> build (settings, options, files)
> File "bin/gub", line 206, in build
> manager = gup.DependencyManager (settings.system_root)
> File "bin/../gub/gup.py", line 353, in __init__
> PackageManager.__init__ (self, *args, **kwargs)
> File "bin/../gub/gup.py", line 314, in __init__
> FileManager.__init__ (self, root, **kwargs)
> File "bin/../gub/gup.py", line 59, in __init__
> self._file_package_db = db.open (files_db, 'c')
> File "/usr/lib/python2.7/anydbm.py", line 84, in open
> mod = __import__(result)
> ImportError: No module named gdbm

Do you have "python-gdbm" installed? Note that GUB uses Python 2, so
not talking about python3-gdbm.

Jonas


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

Re: GUB failure

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: "Thomas Morley" 
Cc: "David Kastrup" ; "Devel" 
Sent: Monday, April 06, 2020 5:02 PM
Subject: Re: GUB failure


I bit the bullet and started the upgrade to 16.04.  I check that's OK then 
consider 18.04 later.  Upgrading via the GUI software updater.




Now with Ubuntu 16.04 and therefore Python 3.5, the build failed.  Any help 
appreciated.  Error was:


Traceback (most recent call last):
File "bin/gub", line 231, in exceptional_build
build (settings, options, files)
File "bin/gub", line 206, in build
manager = gup.DependencyManager (settings.system_root)
File "bin/../gub/gup.py", line 353, in __init__
PackageManager.__init__ (self, *args, **kwargs)
File "bin/../gub/gup.py", line 314, in __init__
FileManager.__init__ (self, root, **kwargs)
File "bin/../gub/gup.py", line 59, in __init__
self._file_package_db = db.open (files_db, 'c')
File "/usr/lib/python2.7/anydbm.py", line 84, in open
mod = __import__(result)
ImportError: No module named gdbm
gub.make:63: recipe for target 'packages' failed
make[1]: *** [packages] Error 1
make[1]: Leaving directory '/home/gub/NewGub/gub'
GNUmakefile:26: recipe for target 'lilypond' failed
make: *** [lilypond] Error 2




--
Phil Holmes 

Re: GUB failure

[Thomas Morley]

Am Di., 7. Apr. 2020 um 10:18 Uhr schrieb Jonas Hahnfeld :
>
> Am Dienstag, den 07.04.2020, 10:12 +0200 schrieb Thomas Morley:
> > Am Di., 7. Apr. 2020 um 09:50 Uhr schrieb David Kastrup <
> > d...@gnu.org
> > >:
> > > Thomas Morley <
> > > thomasmorle...@gmail.com
> > > > writes:
> > >
> > > > Am Mo., 6. Apr. 2020 um 17:18 Uhr schrieb Thomas Morley
> > > > <
> > > > thomasmorle...@gmail.com
> > > > >:
> > > >
> > > > > I'll test GUB with current master on my Ubuntu 18.04, though results
> > > > > likely tomorrow...
> > > >
> > > > FWIW, on my 64-bit Ubunu 18.04, I tried to gub-build release/unstable
> > > >
> > > > (1) gubllb /home/hermann/gub/ /home/hermann/lilypond-git/ 
> > > > release/unstable
> > > > i.e. using Knut's script to build from my local repository
> > > >
> > > > Failed with: FileNotFoundError: [Errno 2] No such file or directory:
> > > > 'book_base.py'
> > >
> > > The question is whether we wait for a followup issue to fix the problem,
> > > or just revert the problematic commit for now.  I lean towards the
> > > latter, to be honest.
> > >
> > > --
> > > David Kastrup
> >
> > Well, I'd test it locally.
> >
> > Though, the naive
> > git revert fa1ec0c100859f7490f524870743f03b54f89ab7
>
> The "offending" commit is ab7a344f689dd9c523f12e818a6f638e1cb7fd4c, not
> sure where above commit id comes from.
>
> Jonas

Hi Jonas,

thanks for the hint, alas

$ git revert ab7a344f689dd9c523f12e818a6f638e1cb7fd4c

returned similar as above:

error: could not revert ab7a344f68... Cleanup python/ build rules.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

Always happy to test, but this is showstopper for me.

Thanks,
  Harm

Re: GUB failure

[Jonas Hahnfeld]

Am Dienstag, den 07.04.2020, 10:12 +0200 schrieb Thomas Morley:
> Am Di., 7. Apr. 2020 um 09:50 Uhr schrieb David Kastrup <
> d...@gnu.org
> >:
> > Thomas Morley <
> > thomasmorle...@gmail.com
> > > writes:
> > 
> > > Am Mo., 6. Apr. 2020 um 17:18 Uhr schrieb Thomas Morley
> > > <
> > > thomasmorle...@gmail.com
> > > >:
> > > 
> > > > I'll test GUB with current master on my Ubuntu 18.04, though results
> > > > likely tomorrow...
> > > 
> > > FWIW, on my 64-bit Ubunu 18.04, I tried to gub-build release/unstable
> > > 
> > > (1) gubllb /home/hermann/gub/ /home/hermann/lilypond-git/ release/unstable
> > > i.e. using Knut's script to build from my local repository
> > > 
> > > Failed with: FileNotFoundError: [Errno 2] No such file or directory:
> > > 'book_base.py'
> > 
> > The question is whether we wait for a followup issue to fix the problem,
> > or just revert the problematic commit for now.  I lean towards the
> > latter, to be honest.
> > 
> > --
> > David Kastrup
> 
> Well, I'd test it locally.
> 
> Though, the naive
> git revert fa1ec0c100859f7490f524870743f03b54f89ab7

The "offending" commit is ab7a344f689dd9c523f12e818a6f638e1cb7fd4c, not
sure where above commit id comes from.

Jonas


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

Re: GUB failure

[Thomas Morley]

Am Di., 7. Apr. 2020 um 09:50 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Am Mo., 6. Apr. 2020 um 17:18 Uhr schrieb Thomas Morley
> > :
> >
> >> I'll test GUB with current master on my Ubuntu 18.04, though results
> >> likely tomorrow...
> >
> > FWIW, on my 64-bit Ubunu 18.04, I tried to gub-build release/unstable
> >
> > (1) gubllb /home/hermann/gub/ /home/hermann/lilypond-git/ release/unstable
> > i.e. using Knut's script to build from my local repository
> >
> > Failed with: FileNotFoundError: [Errno 2] No such file or directory:
> > 'book_base.py'
>
> The question is whether we wait for a followup issue to fix the problem,
> or just revert the problematic commit for now.  I lean towards the
> latter, to be honest.
>
> --
> David Kastrup

Well, I'd test it locally.

Though, the naive
git revert fa1ec0c100859f7490f524870743f03b54f89ab7

returns

Performing inexact rename detection: 100% (17940/17940), done.
error: could not revert fa1ec0c100... Reduce memory use of lilypond-book
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

Here I'm running out of knowledge what to do, supposed I identified
the relevant commit  correctly at all.

Cheers,
  Harm

Re: GUB failure

[Jonas Hahnfeld]

Am Dienstag, den 07.04.2020, 09:50 +0200 schrieb David Kastrup:
> Thomas Morley <
> thomasmorle...@gmail.com
> > writes:
> 
> > Am Mo., 6. Apr. 2020 um 17:18 Uhr schrieb Thomas Morley
> > <
> > thomasmorle...@gmail.com
> > >:
> > 
> > > I'll test GUB with current master on my Ubuntu 18.04, though results
> > > likely tomorrow...
> > 
> > FWIW, on my 64-bit Ubunu 18.04, I tried to gub-build release/unstable
> > 
> > (1) gubllb /home/hermann/gub/ /home/hermann/lilypond-git/ release/unstable
> > i.e. using Knut's script to build from my local repository
> > 
> > Failed with: FileNotFoundError: [Errno 2] No such file or directory:
> > 'book_base.py'
> 
> The question is whether we wait for a followup issue to fix the problem,
> or just revert the problematic commit for now.  I lean towards the
> latter, to be honest.

Or we take the minimal required fix now and postpone the discussion
about __pycache__ directories in the source. Basically a simplified
version of https://codereview.appspot.com/549810043/ should do.
But all of this is meaningless unless Phil has a system to actually
build the release.

Jonas


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

Re: GUB failure

[David Kastrup]

Thomas Morley  writes:

> Am Mo., 6. Apr. 2020 um 17:18 Uhr schrieb Thomas Morley
> :
>
>> I'll test GUB with current master on my Ubuntu 18.04, though results
>> likely tomorrow...
>
> FWIW, on my 64-bit Ubunu 18.04, I tried to gub-build release/unstable
>
> (1) gubllb /home/hermann/gub/ /home/hermann/lilypond-git/ release/unstable
> i.e. using Knut's script to build from my local repository
>
> Failed with: FileNotFoundError: [Errno 2] No such file or directory:
> 'book_base.py'

The question is whether we wait for a followup issue to fix the problem,
or just revert the problematic commit for now.  I lean towards the
latter, to be honest.

-- 
David Kastrup

Re: GUB failure

[Thomas Morley]

Am Mo., 6. Apr. 2020 um 17:18 Uhr schrieb Thomas Morley
:

> I'll test GUB with current master on my Ubuntu 18.04, though results
> likely tomorrow...

FWIW, on my 64-bit Ubunu 18.04, I tried to gub-build release/unstable

(1) gubllb /home/hermann/gub/ /home/hermann/lilypond-git/ release/unstable
i.e. using Knut's script to build from my local repository

Failed with: FileNotFoundError: [Errno 2] No such file or directory:
'book_base.py'

 *** Stage: install (lilypond, linux-64)
MapLocate[/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable]
no files matching pattern: *.la
invoking rm -rf /home/hermann/gub/target/linux-64/install/lilypond-2.21.0-root
invoking cd 
/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable
&& make  TARGET_PYTHON=/usr/bin/python
DESTDIR=/home/hermann/gub/target/linux-64/install/lilypond-2.21.0-root
install
Traceback (most recent call last):
  File 
"/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable/scripts/build/out/install",
line 77, in 
shutil.copy2 (f, dest)
  File "/usr/lib/python3.6/shutil.py", line 263, in copy2
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.6/shutil.py", line 120, in copyfile
with open(src, 'rb') as fsrc:
FileNotFoundError: [Errno 2] No such file or directory: 'book_base.py'
make[1]: *** [local-install-outfiles] Error 1
make: *** [install] Error 2
Command barfed: cd
/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable
&& make  TARGET_PYTHON=/usr/bin/python
DESTDIR=/home/hermann/gub/target/linux-64/install/lilypond-2.21.0-root
install
Traceback (most recent call last):
  File "bin/gub", line 231, in exceptional_build
build (settings, options, files)
  File "bin/gub", line 227, in build
b.build_source_packages (names)
  File "bin/../gub/buildrunner.py", line 334, in build_source_packages
self.spec_build (spec_name)
  File "bin/../gub/buildrunner.py", line 262, in spec_build
deferred_runner.execute_deferred_commands ()
  File "bin/../gub/runner.py", line 167, in execute_deferred_commands
cmd.execute (self.logger)
  File "bin/../gub/commands.py", line 75, in execute
ignore_errors=self.ignore_errors)
  File "bin/../gub/loggedos.py", line 93, in system
raise misc.SystemFailed (m)
SystemFailed: Command barfed: cd
/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable
&& make  TARGET_PYTHON=/usr/bin/python
DESTDIR=/home/hermann/gub/target/linux-64/install/lilypond-2.21.0-root
install

Although:

~/gub (master)$ find -name book_base.py
./target/linux-64/src/lilypond-localhost--lilypond.git-release-unstable/python/book_base.py
./target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable/python/out/book_base.py
./target/darwin-x86/installer/LilyPond.app/Contents/Resources/share/lilypond/current/python/book_base.py
./target/darwin-ppc/installer/LilyPond.app/Contents/Resources/share/lilypond/current/python/book_base.py


As far as I can tell the more "official method" fails with the same problem:
(2) make LILYPOND_BRANCH=release/unstable lilypond

failed with: FileNotFoundError: [Errno 2] No such file or directory:
'book_base.py'

 *** Stage: install (lilypond, linux-64)
MapLocate[/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable]
no files matching pattern: *.la
invoking rm -rf /home/hermann/gub/target/linux-64/install/lilypond-2.21.0-root
invoking cd 
/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable
&& make  TARGET_PYTHON=/usr/bin/python
DESTDIR=/home/hermann/gub/target/linux-64/install/lilypond-2.21.0-root
install
Traceback (most recent call last):
  File 
"/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable/scripts/build/out/install",
line 77, in 
shutil.copy2 (f, dest)
  File "/usr/lib/python3.6/shutil.py", line 263, in copy2
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.6/shutil.py", line 120, in copyfile
with open(src, 'rb') as fsrc:
FileNotFoundError: [Errno 2] No such file or directory: 'book_base.py'
make[1]: *** [local-install-outfiles] Error 1
make: *** [install] Error 2
Command barfed: cd
/home/hermann/gub/target/linux-64/build/lilypond-localhost--lilypond.git-release-unstable
&& make  TARGET_PYTHON=/usr/bin/python
DESTDIR=/home/hermann/gub/target/linux-64/install/lilypond-2.21.0-root
install
Traceback (most recent call last):
  File "bin/gub", line 231, in exceptional_build
build (settings, options, files)
  File "bin/gub", line 227, in build
b.build_source_packages (names)
  File "bin/../gub/buildrunner.py", line 334, in build_source_packages
self.spec_build (spec_name)
  File "bin/../gub/buildrunner.py", line 262, in spec_build
deferred_runner.execute_deferred_commands ()
  File "bin/../gub/runner.py", line 167, in 

Re: GUB failure

[Phil Holmes]

I bit the bullet and started the upgrade to 16.04.  I check that's OK then 
consider 18.04 later.  Upgrading via the GUI software updater.


--
Phil Holmes


- Original Message - 
From: "Thomas Morley" 

To: "Phil Holmes" 
Cc: "David Kastrup" ; "Devel" 
Sent: Monday, April 06, 2020 4:18 PM
Subject: Re: GUB failure


Am Mo., 6. Apr. 2020 um 16:52 Uhr schrieb Phil Holmes 
:


As predicted, GUB has failed to build on my system.  The error message 
shows

that it's because I have Python 3.4.3 and I need at least 3.5.  If anyone
knows how to upgrade my Ubuntu 14 machine to the later Python version,
please say.


Probably
http://ubuntuhandbook.org/index.php/2017/07/install-python-3-6-1-in-ubuntu-16-04-lts/
adapted to your needs may help.


Otherwise I'll have to upgrade to Ubuntu 16, which I was
avoiding while I still had a working installation.


_If_ you need to upgrade, why not newest Ubuntu?

I'll test GUB with current master on my Ubuntu 18.04, though results
likely tomorrow...

Cheers,
 Harm

Re: GUB failure

[Thomas Morley]

Am Mo., 6. Apr. 2020 um 16:52 Uhr schrieb Phil Holmes :
>
> As predicted, GUB has failed to build on my system.  The error message shows
> that it's because I have Python 3.4.3 and I need at least 3.5.  If anyone
> knows how to upgrade my Ubuntu 14 machine to the later Python version,
> please say.

Probably
http://ubuntuhandbook.org/index.php/2017/07/install-python-3-6-1-in-ubuntu-16-04-lts/
adapted to your needs may help.

> Otherwise I'll have to upgrade to Ubuntu 16, which I was
> avoiding while I still had a working installation.

_If_ you need to upgrade, why not newest Ubuntu?

I'll test GUB with current master on my Ubuntu 18.04, though results
likely tomorrow...

Cheers,
  Harm

Re: GUB failure

[Matthew Peveler]

On Mon, Apr 6, 2020 at 11:52 PM Phil Holmes  wrote:

> If anyone knows how to upgrade my Ubuntu 14 machine to the later Python
> version,
> please say.


You can use the deadsnakes ppa (fkrull/deadsnakes
 for pre
Ubuntu-16.04, deadsnakes/ppa
 otherwise) to
install non-included versions of python on Ubuntu distros:sudo

add-apt-repository --yes ppa:fkrull/deadsnakes
sudo apt-get update
sudo apt-get install --yes python3.5 python3.5-dev

You will have to manually install pip I believe doing:
wget https://bootstrap.pypa.io/get-pip.py
sudo python3.5 get-pip.py

Re: GUB failure

[David Kastrup]

"Phil Holmes"  writes:

> As predicted, GUB has failed to build on my system.  The error message
> shows that it's because I have Python 3.4.3 and I need at least 3.5.
> If anyone knows how to upgrade my Ubuntu 14 machine to the later
> Python version, please say.  Otherwise I'll have to upgrade to Ubuntu
> 16, which I was avoiding while I still had a working installation.

Well, I think the LTS installations at that time were supported for
5 years.  I am not sure that upgrading to 16 would still work.  The
usual is to do

sudo update-manager

and follow suggestions for how to upgrade distributions.  There is also
the more explicit

sudo update-manager -d

but it tends to offer updates to the newest release (possibly
prerelease) rather than the latest stable.

-- 
David Kastrup

Re: Gub failure

[Federico Bruni]

Il giorno mer 27 lug 2016 alle 16:08, David Kastrup  ha 
scritto:

Federico Bruni  writes:


 Current developers using LilyDev can update this way:

 1. Add this line to /etc/apt/sources.list:

 deb http://httpredir.debian.org/debian testing main


 2. Add the file /etc/apt/preferences with the following content:

 Package: texinfo
 Pin: release a=testing
 Pin-Priority: 900


 3. Install the new version with:

 sudo apt-get update
 sudo apt-get -t testing install texinfo


Folks, LilyDev is mainly intended for those developers who are not
native/regular GNU/Linux users.  Having them pin packages and add
non-standard sources is a great idea for getting their systems into a
state from which they cannot recover themselves and which nobody else
can diagnose without an account.


It's a standard source.
New developers will use the new ISO and don't have to bother with these 
instructions. Current developers can easily apply these changes to 
their current LilyDev.


Pinning may be problematic if enabled for all packages, but this is 
applied to a single package. I don't think that it's going to cause 
troubles.




Let's just not rush requiring new Texinfo features.

--
David Kastrup



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

Re: Gub failure

[David Kastrup]

Federico Bruni  writes:

> Current developers using LilyDev can update this way:
>
> 1. Add this line to /etc/apt/sources.list:
>
> deb http://httpredir.debian.org/debian testing main
>
>
> 2. Add the file /etc/apt/preferences with the following content:
>
> Package: texinfo
> Pin: release a=testing
> Pin-Priority: 900
>
>
> 3. Install the new version with:
>
> sudo apt-get update
> sudo apt-get -t testing install texinfo

Folks, LilyDev is mainly intended for those developers who are not
native/regular GNU/Linux users.  Having them pin packages and add
non-standard sources is a great idea for getting their systems into a
state from which they cannot recover themselves and which nobody else
can diagnose without an account.

Let's just not rush requiring new Texinfo features.

-- 
David Kastrup

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

Re: Gub failure

[Federico Bruni]

Il giorno mer 27 lug 2016 alle 12:41, Phil Holmes  
ha scritto:
Gub is now updated and uploading.  I would suggest that it is not 
necessary
to wait for LilyDev to be updated, since I would certainly not 
download the
whole image just to get an updated version of texinfo.  Could we not 
just

add the instructions in a note to devel and an update to the CG?

Don't get me wrong - I think an update to LilyDev is a very good 
idea.  I

just don't think it will help most current developers.


I agree.
I'll update LilyDev and upload a new ISO file in a few days.

Current developers using LilyDev can update this way:

1. Add this line to /etc/apt/sources.list:

deb http://httpredir.debian.org/debian testing main


2. Add the file /etc/apt/preferences with the following content:

Package: texinfo
Pin: release a=testing
Pin-Priority: 900


3. Install the new version with:

sudo apt-get update
sudo apt-get -t testing install texinfo




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

Re: Gub failure

[David Kastrup]

"Phil Holmes" <m...@philholmes.net> writes:

> - Original Message - 
> From: "Werner LEMBERG" <w...@gnu.org>
> To: <d...@gnu.org>
> Cc: <lilypond-devel@gnu.org>
> Sent: Wednesday, July 27, 2016 5:21 AM
> Subject: Re: Gub failure
>
>
>>
>>>> I should have made it clear that I asked because my build is
>>>> failing.  I’ve got makeinfo version 4.13.
>>>
>>> That's because Werner pushed changes requiring newer Texinfo syntax.
>>> Werner, can you fix this until systems like Gub and LilyDev 3 can
>>> support it?  It is not realistic to expect people getting this to work
>>> within days on all platforms interested in using LilyPond.
>>
>> Done (in staging).  Please write to the list as soon as gub and
>> lilydev are updated so that I can activate it again!
>>
>>
>>Werner
>
> Gub is now updated and uploading.  I would suggest that it is not
> necessary to wait for LilyDev to be updated, since I would certainly
> not download the whole image just to get an updated version of
> texinfo.  Could we not just add the instructions in a note to devel
> and an update to the CG?
>
> Don't get me wrong - I think an update to LilyDev is a very good idea.
> I just don't think it will help most current developers.

But a new developer getting LilyDev and not being able to make it
compile LilyPond is not exactly solid recruitment.

-- 
David Kastrup

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

Re: Gub failure

[Phil Holmes]

- Original Message - 
From: "Werner LEMBERG" <w...@gnu.org>

To: <d...@gnu.org>
Cc: <lilypond-devel@gnu.org>
Sent: Wednesday, July 27, 2016 5:21 AM
Subject: Re: Gub failure





I should have made it clear that I asked because my build is
failing.  I’ve got makeinfo version 4.13.


That's because Werner pushed changes requiring newer Texinfo syntax.
Werner, can you fix this until systems like Gub and LilyDev 3 can
support it?  It is not realistic to expect people getting this to work
within days on all platforms interested in using LilyPond.


Done (in staging).  Please write to the list as soon as gub and
lilydev are updated so that I can activate it again!


   Werner


Gub is now updated and uploading.  I would suggest that it is not necessary 
to wait for LilyDev to be updated, since I would certainly not download the 
whole image just to get an updated version of texinfo.  Could we not just 
add the instructions in a note to devel and an update to the CG?


Don't get me wrong - I think an update to LilyDev is a very good idea.  I 
just don't think it will help most current developers.


--
Phil Holmes 



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

Re: Gub failure

[David Kastrup]

Federico Bruni  writes:

> Il giorno mar 26 lug 2016 alle 19:36, Dan Eble  ha
> scritto:
>> I should have made it clear that I asked because my build is failing.
>> I’ve got makeinfo version 4.13.
>
> Are you sure that you are using LilyDev 3? It is based on Debian
> stable (Jessie) and texinfo is version 5.2:
> https://packages.debian.org/jessie/texinfo
>
> I may install version 6.1 from testing in next LilyDev release, if
> this helps.

My guess is that it will help performance.  5 was a serious step down
(due to the porting of C to Perl) and I believe that was a bit of focus
for complaints.  So it would seem like an optimistic guess that
performance was also a bit of focus.

The Texinfo 6.0 release news state: "texi2any: [...] a bit faster".

6.1 notes state:

* texi2any:
  . Some Perl modules have been rewritten in C to increase speed.
If Perl extensions can be created, they are used by default;
otherwise the pure Perl implementations are still used.
Disable at build time with "configure --disable-perl-xs".  The
environment variable TEXINFO_XS controls how they are used by
texi2any.

Let's hope that the right modules have been rewritten and that the
architecture of texi2any is well-suited to exploiting the gains.

-- 
David Kastrup

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

Re: Gub failure

[Federico Bruni]

Il giorno mar 26 lug 2016 alle 19:36, Dan Eble  ha 
scritto:

I should have made it clear that I asked because my build is failing.
I’ve got makeinfo version 4.13.


Are you sure that you are using LilyDev 3? It is based on Debian stable 
(Jessie) and texinfo is version 5.2:

https://packages.debian.org/jessie/texinfo

I may install version 6.1 from testing in next LilyDev release, if this 
helps.





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

Re: Gub failure

[Werner LEMBERG]

>> I should have made it clear that I asked because my build is
>> failing.  I’ve got makeinfo version 4.13.
> 
> That's because Werner pushed changes requiring newer Texinfo syntax.
> Werner, can you fix this until systems like Gub and LilyDev 3 can
> support it?  It is not realistic to expect people getting this to work
> within days on all platforms interested in using LilyPond.

Done (in staging).  Please write to the list as soon as gub and
lilydev are updated so that I can activate it again!


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

Re: Gub failure

[David Kastrup]

Dan Eble  writes:

>> On Jul 26, 2016, at 07:57 , David Kastrup  wrote:
>> 
>> Dan Eble  writes:
>> 
>>> In LilyDev 3, I’ve tried “sudo apt-get install texinfo” and it tells
>>> me “texinfo is already the newest version.”  Is there any easier path
>>> forward than switching to a new VM?  Would the latest LilyDev be
>>> sufficient?
>> 
>> LilyDev might well have a later version of Texinfo than Gub has.  Try
>> 
>> makeinfo --version
>
> I should have made it clear that I asked because my build is failing.
> I’ve got makeinfo version 4.13.

That's because Werner pushed changes requiring newer Texinfo syntax.
Werner, can you fix this until systems like Gub and LilyDev 3 can
support it?  It is not realistic to expect people getting this to work
within days on all platforms interested in using LilyPond.

-- 
David Kastrup

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

Re: Gub failure

[Dan Eble]

> On Jul 26, 2016, at 07:57 , David Kastrup  wrote:
> 
> Dan Eble  writes:
> 
>> In LilyDev 3, I’ve tried “sudo apt-get install texinfo” and it tells
>> me “texinfo is already the newest version.”  Is there any easier path
>> forward than switching to a new VM?  Would the latest LilyDev be
>> sufficient?
> 
> LilyDev might well have a later version of Texinfo than Gub has.  Try
> 
> makeinfo --version

I should have made it clear that I asked because my build is failing.
I’ve got makeinfo version 4.13.
— 
Dan


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

Re: Gub failure

[Masamichi Hosoda]

> I've accepted the pull requests on GitHub and updated my system as
> above. I'm now getting a failure rebuilding Guile.  I've attached the
> end of the logfile to avoid problems with line wrapping making the
> error messages unintelligible.

I've created pull request for fixing guile compilation.
https://github.com/gperciva/gub/pull/26

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

Re: Gub failure

[Phil Holmes]

- Original Message - 
From: "Masamichi Hosoda" <truer...@trueroad.jp>
To: <w...@gnu.org>; <m...@philholmes.net>; <d...@gnu.org>; 
<lilypond-devel@gnu.org>

Sent: Monday, July 25, 2016 3:41 PM
Subject: Re: Gub failure



Please use 5.x – 4.x is no longer supported.


Or even better 6.x.


I've created pull request for updating texinfo to 6.1.
https://github.com/gperciva/gub/pull/25

In my GUB environment, the following commands are succeed.

$ bin/gub tools::texinfo
$ bin/gub linux-64::lilypond
$ bin/gub linux-64::lilypond-doc



I've accepted the pull requests on GitHub and updated my system as above. 
I'm now getting a failure rebuilding Guile.  I've attached the end of the 
logfile to avoid problems with line wrapping making the error messages 
unintelligible.


--
Phil Holmes 

/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/gh.texi:1000: 
must be after `@deftypefun' to use `@deftypefunx'
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/fdl.texi:411: 
raising the section level of @appendixsubsec which is too low
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-utility.texi:566:
 warning: node `C Hooks' is next for `Hook Reference' in menu but not in 
sectioning
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-utility.texi:674:
 warning: node `Hook Reference' is prev for `C Hooks' in menu but not in 
sectioning
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-options.texi:510:
 warning: node next `Printing options' in menu `Debugger options' and in 
sectioning `Evaluator options' differ
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-options.texi:533:
 warning: node prev `Evaluator options' in menu `Debugger options' and in 
sectioning `Printing options' differ
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-options.texi:544:
 warning: node next `Evaluator trap options' in menu `Examples of option use' 
and in sectioning `Debugger options' differ
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-options.texi:625:
 warning: node next `Debugger options' in menu `Evaluator options' and in 
sectioning `Examples of option use' differ
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-options.texi:625:
 warning: node prev `Debugger options' in menu `Printing options' and in 
sectioning `Evaluator trap options' differ
/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/api-options.texi:681:
 warning: node prev `Examples of option use' in menu `Evaluator trap options' 
and in sectioning `Debugger options' differ
mv: target './/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/' 
is not a directory
make[2]: *** 
[/home/gub/NewGub/gub/target/freebsd-x86/src/guile-1.8.7/doc/ref/guile.info] 
Error 1
make[2]: Leaving directory 
`/home/gub/NewGub/gub/target/freebsd-x86/build/guile-1.8.7/doc/ref'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory 
`/home/gub/NewGub/gub/target/freebsd-x86/build/guile-1.8.7/doc'
make: *** [install-recursive] Error 1
Command barfed: cd /home/gub/NewGub/gub/target/freebsd-x86/build/guile-1.8.7 && make   DESTDIR=/home/gub/NewGub/gub/target/freebsd-x86/install/guile-1.8.7-root install 
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Gub failure

[David Kastrup]

Dan Eble  writes:

> On Jul 24, 2016, at 13:32 , David Kastrup  wrote:
>> 
>> Note that even "make" builds a basic non-image version of the Info
>> files, and of course with a non-image version, the difference is quite
>> noticeable.
>> 
>> At any rate, if we were to update Texinfo, it would likely make sense to
>> take the newest available version since then some of the performance
>> regression is likely to have seen some improvement.  I am not actually
>> sure about the indexing improvements, however: it may be that they are
>> only in PDF yet anyway, and in that case we probably already have them
>> since our texinfo.tex in the main tarball is much more up-to-date than
>> the Texinfo binaries.
>
> In LilyDev 3, I’ve tried “sudo apt-get install texinfo” and it tells
> me “texinfo is already the newest version.”  Is there any easier path
> forward than switching to a new VM?  Would the latest LilyDev be
> sufficient?

LilyDev might well have a later version of Texinfo than Gub has.  Try

makeinfo --version

-- 
David Kastrup

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

Re: Gub failure

[Dan Eble]

On Jul 24, 2016, at 13:32 , David Kastrup  wrote:
> 
> Note that even "make" builds a basic non-image version of the Info
> files, and of course with a non-image version, the difference is quite
> noticeable.
> 
> At any rate, if we were to update Texinfo, it would likely make sense to
> take the newest available version since then some of the performance
> regression is likely to have seen some improvement.  I am not actually
> sure about the indexing improvements, however: it may be that they are
> only in PDF yet anyway, and in that case we probably already have them
> since our texinfo.tex in the main tarball is much more up-to-date than
> the Texinfo binaries.

In LilyDev 3, I’ve tried “sudo apt-get install texinfo” and it tells me 
“texinfo is already the newest version.”  Is there any easier path forward than 
switching to a new VM?  Would the latest LilyDev be sufficient?

Thanks,
— 
Dan


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

Re: Gub failure

[Masamichi Hosoda]

>> Please use 5.x – 4.x is no longer supported.
> 
> Or even better 6.x.

I've created pull request for updating texinfo to 6.1.
https://github.com/gperciva/gub/pull/25

In my GUB environment, the following commands are succeed.

$ bin/gub tools::texinfo
$ bin/gub linux-64::lilypond
$ bin/gub linux-64::lilypond-doc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Gub failure

[Werner LEMBERG]

> Please use 5.x – 4.x is no longer supported.

Or even better 6.x.


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

Re: Gub failure

[David Kastrup]

"Phil Holmes" <m...@philholmes.net> writes:

> - Original Message - 
> From: "David Kastrup" <d...@gnu.org>
> To: "Werner LEMBERG" <w...@gnu.org>
> Cc: <m...@philholmes.net>; <lilypond-devel@gnu.org>
> Sent: Sunday, July 24, 2016 5:57 PM
> Subject: Re: Gub failure
>
>
>> Werner LEMBERG <w...@gnu.org> writes:
>>
>>>> Maybe gub still contains an older version?  Sorry for not having
>>>> checked that before committing.
>>>
>>> Indeed, I now see that only texinfo 4.11 is required.
>>>
>>> How to proceed?  Reverting is easy (commit
>>> 445bf3bb2fbd1f259fe43ade204fb34d68bdd581, the changes in
>>> `macros.itexi').  However, I would prefer if we update to a newer
>>> version of texinfo.
>>
>> Texinfo 5 is vastly slower and this might make an impact on Gub times.
>> On the other hand, stuff like the improved indexing requires fairly
>> recent versions of Texinfo.
>>
>> -- 
>> David Kastrup
>
>
> Gub takes such an extraordinary time to build, it probably wouldn't
> make much difference.  On my core i7, quad core, 8 cpu system, a full
> build from scratch takes over a day.  The shortest time I ever get
> from a good previous build is about an hour and a half.  A standard
> make doc is about 16 minutes.

Note that even "make" builds a basic non-image version of the Info
files, and of course with a non-image version, the difference is quite
noticeable.

At any rate, if we were to update Texinfo, it would likely make sense to
take the newest available version since then some of the performance
regression is likely to have seen some improvement.  I am not actually
sure about the indexing improvements, however: it may be that they are
only in PDF yet anyway, and in that case we probably already have them
since our texinfo.tex in the main tarball is much more up-to-date than
the Texinfo binaries.

-- 
David Kastrup

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

Re: Gub failure

[Werner LEMBERG]

> OK - so it looks like I should update
> https://github.com/gperciva/gub/blob/master/gub/sources.py to a later
> version of texinfo - possibly 4.13 to move forward but not risk a
> breakage with a new major release?

Please use 5.x – 4.x is no longer supported.  At least on my box I can
easily build all documentation without any problems, as far as I can
see.

> I note that there are a couple of patch files for texinfo in
> https://github.com/gperciva/gub/tree/master/patches.  Not sure what to
> do with these - possibly nothing and see what happens?

Yes, I think this is the best course of action.


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

Re: Gub failure

[Phil Holmes]

- Original Message - 
From: "David Kastrup" <d...@gnu.org>

To: "Werner LEMBERG" <w...@gnu.org>
Cc: <m...@philholmes.net>; <lilypond-devel@gnu.org>
Sent: Sunday, July 24, 2016 5:57 PM
Subject: Re: Gub failure



Werner LEMBERG <w...@gnu.org> writes:


Maybe gub still contains an older version?  Sorry for not having
checked that before committing.


Indeed, I now see that only texinfo 4.11 is required.

How to proceed?  Reverting is easy (commit
445bf3bb2fbd1f259fe43ade204fb34d68bdd581, the changes in
`macros.itexi').  However, I would prefer if we update to a newer
version of texinfo.


Texinfo 5 is vastly slower and this might make an impact on Gub times.
On the other hand, stuff like the improved indexing requires fairly
recent versions of Texinfo.

--
David Kastrup



Gub takes such an extraordinary time to build, it probably wouldn't make 
much difference.  On my core i7, quad core, 8 cpu system, a full build from 
scratch takes over a day.  The shortest time I ever get from a good previous 
build is about an hour and a half.  A standard make doc is about 16 minutes.


--
Phil Holmes 



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

Re: Gub failure

[David Kastrup]

Werner LEMBERG  writes:

>> Maybe gub still contains an older version?  Sorry for not having
>> checked that before committing.
>
> Indeed, I now see that only texinfo 4.11 is required.
>
> How to proceed?  Reverting is easy (commit
> 445bf3bb2fbd1f259fe43ade204fb34d68bdd581, the changes in
> `macros.itexi').  However, I would prefer if we update to a newer
> version of texinfo.

Texinfo 5 is vastly slower and this might make an impact on Gub times.
On the other hand, stuff like the improved indexing requires fairly
recent versions of Texinfo.

-- 
David Kastrup

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

Re: Gub failure

[Phil Holmes]

- Original Message - 
From: "Werner LEMBERG" <w...@gnu.org>

To: <m...@philholmes.net>
Cc: <d...@gnu.org>; <lilypond-devel@gnu.org>
Sent: Sunday, July 24, 2016 5:04 PM
Subject: Re: Gub failure





Maybe gub still contains an older version?  Sorry for not having
checked that before committing.


Indeed, I now see that only texinfo 4.11 is required.

How to proceed?  Reverting is easy (commit
445bf3bb2fbd1f259fe43ade204fb34d68bdd581, the changes in
`macros.itexi').  However, I would prefer if we update to a newer
version of texinfo.


   Werner



OK - so it looks like I should update 
https://github.com/gperciva/gub/blob/master/gub/sources.py to a later 
version of texinfo - possibly 4.13 to move forward but not risk a breakage 
with a new major release?


I note that there are a couple of patch files for texinfo in 
https://github.com/gperciva/gub/tree/master/patches.  Not sure what to do 
with these - possibly nothing and see what happens?


--
Phil Holmes 



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

Re: Gub failure

[Werner LEMBERG]

> Maybe gub still contains an older version?  Sorry for not having
> checked that before committing.

Indeed, I now see that only texinfo 4.11 is required.

How to proceed?  Reverting is easy (commit
445bf3bb2fbd1f259fe43ade204fb34d68bdd581, the changes in
`macros.itexi').  However, I would prefer if we update to a newer
version of texinfo.


Werner

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

Re: Gub failure

[David Kastrup]

"Phil Holmes"  writes:

> Looks like this was the problem.  I had to edit the file and push it
> to release/unstable since Gub always seems to pull its source files
> from there, so editing locally doesn't work.  My normal course would
> be to push this change to staging once I've uploaded the new builds
> and docs.  Does that seem OK in this case?

I think so.  New builds and docs include a regtest build so I don't
think we have to fathom staging failures if you managed a build.
Particularly not for this change.

-- 
David Kastrup

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

Re: Gub failure

[Werner LEMBERG]

> I now got as far as make doc, when the build failed making
> notation.makeinfo, with lots of errors similar to this:
> 
> /home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/out-www//notation/pitches.texi:4417:
> Unknown command `raggedright'.
> /home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/out-www//notation/pitches.texi:4420:
> Unmatched `@end'.

Oh, you need texinfo 5.0 or newer, released more than three years
ago...

Maybe gub still contains an older version?  Sorry for not having
checked that before committing.


Werner

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

Re: Gub failure

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" <m...@philholmes.net>

To: "David Kastrup" <d...@gnu.org>
Cc: <lilypond-devel@gnu.org>
Sent: Sunday, July 24, 2016 3:53 PM
Subject: Re: Gub failure


- Original Message - 
From: "David Kastrup" <d...@gnu.org>

To: "Phil Holmes" <m...@philholmes.net>
Cc: <lilypond-devel@gnu.org>
Sent: Sunday, July 24, 2016 12:15 PM
Subject: Re: Gub failure



Phil Holmes <m...@philholmes.net> writes:


Trying to build Gub today, I get the following failures:

/home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
release-unstable/lily/dynamic-performer.cc: In member function 'Real
Dynamic_performer::compute_departure_volume(Direction, Real, Real, Real,
Real)':
/home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
release-unstable/lily/dynamic-performer.cc:259:19: error: expected
unqualified-id before '=' token
   const Real near = minmax (depart_dir, start_vol, end_vol)
   ^
/home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
release-unstable/lily/dynamic-performer.cc:261:18: error: expected
unqualified-id before '=' token
   const Real far = minmax (-depart_dir, start_vol, end_vol)
  ^
There are further similar errors.

Anyone know what's going on?


"target/mingw" would be seminal here I think.  I am surprised that we
are getting this even when crosscompiling with GCC but at any rate in
Microsoft compilers, "far"/"near" are keywords indicating
pointer/segmentation type.  So when working with system headers, GCC is
likely to assign some sort of meaning to those words (via preprocessor
if not via core language).

Try replacing the occurences of the identifiers "far" and "near" with
"far_vol" and "near_vol" (I haven't looked at the actual code so this
name might or might not be appropriate) and see whether this makes Gub
happier.

--
David Kastrup



Looks like this was the problem.  I had to edit the file and push it to 
release/unstable since Gub always seems to pull its source files from 
there, so editing locally doesn't work.  My normal course would be to push 
this change to staging once I've uploaded the new builds and docs.  Does 
that seem OK in this case?


--
Phil Holmes


I now got as far as make doc, when the build failed making 
notation.makeinfo, with lots of errors similar to this:


/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/out-www//notation/pitches.texi:4417: 
Unknown command `raggedright'.
/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/out-www//notation/pitches.texi:4420: 
Unmatched `@end'.





--
Phil Holmes 



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

Re: Gub failure

[Phil Holmes]

- Original Message - 
From: "David Kastrup" <d...@gnu.org>

To: "Phil Holmes" <m...@philholmes.net>
Cc: <lilypond-devel@gnu.org>
Sent: Sunday, July 24, 2016 12:15 PM
Subject: Re: Gub failure



Phil Holmes <m...@philholmes.net> writes:


Trying to build Gub today, I get the following failures:

/home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
release-unstable/lily/dynamic-performer.cc: In member function 'Real
Dynamic_performer::compute_departure_volume(Direction, Real, Real, Real,
Real)':
/home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
release-unstable/lily/dynamic-performer.cc:259:19: error: expected
unqualified-id before '=' token
   const Real near = minmax (depart_dir, start_vol, end_vol)
   ^
/home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
release-unstable/lily/dynamic-performer.cc:261:18: error: expected
unqualified-id before '=' token
   const Real far = minmax (-depart_dir, start_vol, end_vol)
  ^
There are further similar errors.

Anyone know what's going on?


"target/mingw" would be seminal here I think.  I am surprised that we
are getting this even when crosscompiling with GCC but at any rate in
Microsoft compilers, "far"/"near" are keywords indicating
pointer/segmentation type.  So when working with system headers, GCC is
likely to assign some sort of meaning to those words (via preprocessor
if not via core language).

Try replacing the occurences of the identifiers "far" and "near" with
"far_vol" and "near_vol" (I haven't looked at the actual code so this
name might or might not be appropriate) and see whether this makes Gub
happier.

--
David Kastrup



Looks like this was the problem.  I had to edit the file and push it to 
release/unstable since Gub always seems to pull its source files from there, 
so editing locally doesn't work.  My normal course would be to push this 
change to staging once I've uploaded the new builds and docs.  Does that 
seem OK in this case?


--
Phil Holmes 



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

Re: Gub failure

[David Kastrup]

Phil Holmes  writes:

> Trying to build Gub today, I get the following failures:
>
> /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
> release-unstable/lily/dynamic-performer.cc: In member function 'Real 
> Dynamic_performer::compute_departure_volume(Direction, Real, Real, Real, 
> Real)':
> /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
> release-unstable/lily/dynamic-performer.cc:259:19: error: expected 
> unqualified-id before '=' token
>const Real near = minmax (depart_dir, start_vol, end_vol)
>^
> /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-
> release-unstable/lily/dynamic-performer.cc:261:18: error: expected 
> unqualified-id before '=' token
>const Real far = minmax (-depart_dir, start_vol, end_vol)
>   ^
> There are further similar errors.
>
> Anyone know what's going on?

"target/mingw" would be seminal here I think.  I am surprised that we
are getting this even when crosscompiling with GCC but at any rate in
Microsoft compilers, "far"/"near" are keywords indicating
pointer/segmentation type.  So when working with system headers, GCC is
likely to assign some sort of meaning to those words (via preprocessor
if not via core language).

Try replacing the occurences of the identifiers "far" and "near" with
"far_vol" and "near_vol" (I haven't looked at the actual code so this
name might or might not be appropriate) and see whether this makes Gub
happier.

-- 
David Kastrup

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

Re: Gub failure

[Masamichi Hosoda]

Phil,

>> make[1]: *** No rule to make target 
>> `/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include/freetype2/freetype/ftxf86.h',
>>  needed by `out/pango-font.o'.  Stop.
>> make[1]: *** Waiting for unfinished jobs
> 
> Ouch.  It seems that this is an old pango version that calls FreeType
> header files directly instead of using the canonical macro names.
> 
> The file `ftxf86.h' no longer exists; it has been renamed to
> `ftfntfmt.h' in FreeType version 2.6.  However, the macro to access
> this file, FT_XFREE86_H, hasn't changed.
> 
> Perhaps it makes sense to upgrade Pango...

Would you rebuild pango?

$ rm -f target/*/package/pango*
$ make lilypond

Or, if you have a lot of time, you may try whole rebuilding as following.

$ rm -fr target/
$ make lilypond

I sometimes try the whole rebuilding
because it is a good way to solve the problem of dependency.
However, it takes so much time.

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

Re: Gub failure

[Werner LEMBERG]

> make[1]: *** No rule to make target 
> `/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include/freetype2/freetype/ftxf86.h',
>  needed by `out/pango-font.o'.  Stop.
> make[1]: *** Waiting for unfinished jobs

Ouch.  It seems that this is an old pango version that calls FreeType
header files directly instead of using the canonical macro names.

The file `ftxf86.h' no longer exists; it has been renamed to
`ftfntfmt.h' in FreeType version 2.6.  However, the macro to access
this file, FT_XFREE86_H, hasn't changed.

Perhaps it makes sense to upgrade Pango...


Werner

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

Re: Gub failure

[David Kastrup]

"Phil Holmes"  writes:

> Attached is a compressed log file.  I see lots of warnings but no errors.

It does not use the text "error" but there is:

make[1]: *** No rule to make target 
`/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include/freetype2/freetype/ftxf86.h',
 needed by `out/pango-font.o'.  Stop.
make[1]: *** Waiting for unfinished jobs

The "unfinished jobs" create so much more output afterwards that you
probably overlooked this problem.

-- 
David Kastrup

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

Re: Gub failure

[Phil Holmes]

Possibly the file is too large to be posted.

Uploaded here: http://philholmes.net/lilypond/lilypond.log.tar.gz

--
Phil Holmes


- Original Message - 
From: "Phil Holmes" 

To: 
Sent: Wednesday, June 08, 2016 2:32 PM
Subject: Gub failure


I'm having trouble building Gub again - the output from the logfile 
doesn't
make much sense to me, but I can attach it once I've sent an initial 
message

from Gmane - I appear to be unable to start threads from my mail client.


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




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

Re: GUB failure

[Phil Holmes]

- Original Message - 
From: "David Kastrup" <d...@gnu.org>

To: "Phil Holmes" <m...@philholmes.net>
Cc: <lilypond-devel@gnu.org>
Sent: Sunday, October 18, 2015 12:43 PM
Subject: Re: GUB failure



Phil Holmes <m...@philholmes.net> writes:


I'm getting the following failure running a GUB build:

/home/gub/NewGub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--
lilypond.git-release-unstable/flower/warn.cc:114:49: warning: format '%d'
expects argument of type 'int', but argument 2 has type
'std::vector<std::basic_string >::size_type {aka long unsigned 
int}'

[-Wformat=]
expected_warnings.size ());
 ^

Presumably caused by

Issue 4550 (n/2) Avoid "using namespace std;" in included files

but I've no idea why.  Can anyone suggest a fix, please?


That's a warning, not an error.  We have other warnings that don't stop
compilation.  While this one would warrant fixing (likely by using
stdstream instead of the C stdio library), it should not make
compilation abort.  Can you check the compilation log for an actual
error?  That would likely be more important to fix right now.  The above
will likely, if at all, "just" cause wrong output in warnings on the PPC
platform.  Definitely something we want to fix, but I think something
else is responsible for making the compilation stop altogether.

--
David Kastrup



OK - thanks.  Should have seen that.  The error (one of a few similar) is:

/home/gub/NewGub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/offset.cc:43:25: 
error: 'isinf' was not declared in this scope

if (!isinf (z2[Y_AXIS]))

Seems to be deja vu all over again.  See the thread at

https://lists.gnu.org/archive/html/lilypond-devel/2015-08/msg00150.html

Not sure why the 4550 patch was repushed?

--
Phil Holmes




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

Re: GUB failure

[Phil Holmes]

- Original Message - 
From: "David Kastrup" <d...@gnu.org>

To: "Phil Holmes" <m...@philholmes.net>
Cc: <lilypond-devel@gnu.org>
Sent: Sunday, October 18, 2015 1:15 PM
Subject: Re: GUB failure



"Phil Holmes" <m...@philholmes.net> writes:

OK - thanks.  Should have seen that.  The error (one of a few similar) 
is:


/home/gub/NewGub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/offset.cc:43:25:
error: 'isinf' was not declared in this scope
if (!isinf (z2[Y_AXIS]))

Seems to be deja vu all over again.  See the thread at

https://lists.gnu.org/archive/html/lilypond-devel/2015-08/msg00150.html

Not sure why the 4550 patch was repushed?


Because a major issue with it had been addressed.  I'll see whether we
can do a reasonably clean revert of this patch in order to make time for
the release.  If not, we'll have to wait for Dan to do the cleanup.

--
David Kastrup



OK - I see your revert in staging. I'll run patchy staging straight away to 
get this into master.


--
Phil Holmes 



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

Re: GUB failure

[David Kastrup]

"Phil Holmes"  writes:

> OK - thanks.  Should have seen that.  The error (one of a few similar) is:
>
> /home/gub/NewGub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/offset.cc:43:25:
> error: 'isinf' was not declared in this scope
> if (!isinf (z2[Y_AXIS]))
>
> Seems to be deja vu all over again.  See the thread at
>
> https://lists.gnu.org/archive/html/lilypond-devel/2015-08/msg00150.html
>
> Not sure why the 4550 patch was repushed?

Because a major issue with it had been addressed.  I'll see whether we
can do a reasonably clean revert of this patch in order to make time for
the release.  If not, we'll have to wait for Dan to do the cleanup.

-- 
David Kastrup

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

Re: GUB failure

[David Kastrup]

David Kastrup  writes:

> "Phil Holmes"  writes:
>
>> OK - thanks.  Should have seen that.  The error (one of a few similar) is:
>>
>> /home/gub/NewGub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/offset.cc:43:25:
>> error: 'isinf' was not declared in this scope
>> if (!isinf (z2[Y_AXIS]))
>>
>> Seems to be deja vu all over again.  See the thread at
>>
>> https://lists.gnu.org/archive/html/lilypond-devel/2015-08/msg00150.html
>>
>> Not sure why the 4550 patch was repushed?
>
> Because a major issue with it had been addressed.  I'll see whether we
> can do a reasonably clean revert of this patch in order to make time for
> the release.  If not, we'll have to wait for Dan to do the cleanup.

I reverted the issue again and pushed the result to staging.  Let's see
whether the next iteration manages to heed the isinf problem.

-- 
David Kastrup

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

Re: GUB failure

[David Kastrup]

Phil Holmes  writes:

> I'm getting the following failure running a GUB build:
>
> /home/gub/NewGub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--
> lilypond.git-release-unstable/flower/warn.cc:114:49: warning: format '%d'
> expects argument of type 'int', but argument 2 has type 
> 'std::vector::size_type {aka long unsigned int}' 
> [-Wformat=]
> expected_warnings.size ());
>  ^
>
> Presumably caused by
>
> Issue 4550 (n/2) Avoid "using namespace std;" in included files
>
> but I've no idea why.  Can anyone suggest a fix, please?

That's a warning, not an error.  We have other warnings that don't stop
compilation.  While this one would warrant fixing (likely by using
stdstream instead of the C stdio library), it should not make
compilation abort.  Can you check the compilation log for an actual
error?  That would likely be more important to fix right now.  The above
will likely, if at all, "just" cause wrong output in warnings on the PPC
platform.  Definitely something we want to fix, but I think something
else is responsible for making the compilation stop altogether.

-- 
David Kastrup

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

Re: GUB failure

[Phil Holmes]

- Original Message - 
From: Masamichi HOSODA truer...@sea.plala.or.jp

To: m...@philholmes.net
Cc: lilypond-devel@gnu.org
Sent: Sunday, August 23, 2015 12:52 PM
Subject: Re: GUB failure


Following the changes to the fonts, I'm now having GUB fail.  The log 
shows:


configure: WARNING: unrecognized 
options: --enable-shared, --disable-static,

--disable-silent-rules, --with-fonts-dir

WARNING: Please consider installing optional programs or files:  dblatex

ERROR: Please install required programs:  TeX Gyre fonts OTF (make sure 
the
fc-list utility can see them, e.g. 'sudo apt-get install fonts-texgyre', 
or

use --with-texgyre-dir)

If I try

sudo apt-get install fonts-texgyre

I get

fonts-texgyre is already the newest version.

Where do I go now?


GUB repository
https://github.com/gperciva/gub
has already been updated for the font changing.

Do you update your local working tree?

If not, it can be updated by something like the following command.

$ git fetch origin
$ git checkout master
$ git merge origin/master



Thanks.  That fixed it.  I always expect GUB to update itself.  Please see 
the mail list for a further error.


--
Phil Holmes 



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

Re: GUB failure

[Masamichi HOSODA]

 Following the changes to the fonts, I'm now having GUB fail.  The log shows:
 
 configure: WARNING: unrecognized options: --enable-shared, --disable-static,
 --disable-silent-rules, --with-fonts-dir
 
 WARNING: Please consider installing optional programs or files:  dblatex
 
 ERROR: Please install required programs:  TeX Gyre fonts OTF (make sure the
 fc-list utility can see them, e.g. 'sudo apt-get install fonts-texgyre', or
 use --with-texgyre-dir)
 
 If I try
 
 sudo apt-get install fonts-texgyre
 
 I get
 
 fonts-texgyre is already the newest version.
 
 Where do I go now?

GUB repository
https://github.com/gperciva/gub
has already been updated for the font changing.

Do you update your local working tree?

If not, it can be updated by something like the following command.

$ git fetch origin
$ git checkout master
$ git merge origin/master

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

Re: GUB failure in parser.yy

[David Kastrup]

Phil Holmes em...@philholmes.net writes:

 I'm trying to build 2.17.3.  I get this failure:

 make[1]: Entering directory
 /home/gub/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily'
 bison -o out/parser-tmp.cc -d 
 /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/parser.yy
 /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/parser.yy:30.1-5:
 invalid directive: `%code'
 /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/parser.yy:30.7-14:
 syntax error, unexpected identifier
 make[1]: *** [out/parser.hh] Error 1

 I'll have another go once this is fixed.

That would likely be a Bison version that is too old.  There are two
options to deal with it:

a) update the required version of Bison in the configure script and in GUB
b) try to make do without %code

I'd prefer option a) since a smaller range of supported versions makes
for fewer surprises, in particular since I was planning to make some
changes soon that will require somewhat predictable details in the
generated Bison code.

It is just the question how much pain requiring newer versions will be.
Let's keep GUB old is not really an overly convincing reason, but if
it breaks other supported configurations, that might be cause to
retract.

-- 
David Kastrup

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

Re: GUB failure in parser.yy

[Phil Holmes]

- Original Message - 
From: David Kastrup d...@gnu.org

To: Phil Holmes em...@philholmes.net
Cc: Devel lilypond-devel@gnu.org
Sent: Saturday, September 22, 2012 4:56 PM
Subject: Re: GUB failure in parser.yy



Phil Holmes em...@philholmes.net writes:


I'm trying to build 2.17.3.  I get this failure:

make[1]: Entering directory
/home/gub/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily'
bison -o out/parser-tmp.cc -d
/home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/parser.yy
/home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/parser.yy:30.1-5:
invalid directive: `%code'
/home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/parser.yy:30.7-14:
syntax error, unexpected identifier
make[1]: *** [out/parser.hh] Error 1

I'll have another go once this is fixed.


That would likely be a Bison version that is too old.  There are two
options to deal with it:

a) update the required version of Bison in the configure script and in GUB
b) try to make do without %code

I'd prefer option a) since a smaller range of supported versions makes
for fewer surprises, in particular since I was planning to make some
changes soon that will require somewhat predictable details in the
generated Bison code.

It is just the question how much pain requiring newer versions will be.
Let's keep GUB old is not really an overly convincing reason, but if
it breaks other supported configurations, that might be cause to
retract.



My preference _right now_ would be to remove the code that's causing the old 
version of Bison a problem.  To fix Gub, rebuild Gub and then rebuild 
lilypond would take considerable time which I don't have now.  I'd like to 
get an updated version of lilypond out over this weekend.  I'd be happy to 
discuss how to update Gub and then rebuild it starting next week.


--
Phil Holmes 



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

Re: GUB failure in parser.yy

[David Kastrup]

Phil Holmes m...@philholmes.net writes:

 My preference _right now_ would be to remove the code that's causing
 the old version of Bison a problem.  To fix Gub, rebuild Gub and then
 rebuild lilypond would take considerable time which I don't have now.
 I'd like to get an updated version of lilypond out over this weekend.
 I'd be happy to discuss how to update Gub and then rebuild it starting
 next week.

Trickier than expected, just changing lily/parser.yy was not enough.

URL:http://code.google.com/p/lilypond/issues/detail?id=2855

-- 
David Kastrup

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

Re: GUB failure in parser.yy

[Phil Holmes]

- Original Message - 
From: David Kastrup d...@gnu.org

To: Phil Holmes m...@philholmes.net
Cc: Devel lilypond-devel@gnu.org
Sent: Saturday, September 22, 2012 6:38 PM
Subject: Re: GUB failure in parser.yy



Phil Holmes m...@philholmes.net writes:


My preference _right now_ would be to remove the code that's causing
the old version of Bison a problem.  To fix Gub, rebuild Gub and then
rebuild lilypond would take considerable time which I don't have now.
I'd like to get an updated version of lilypond out over this weekend.
I'd be happy to discuss how to update Gub and then rebuild it starting
next week.


Trickier than expected, just changing lily/parser.yy was not enough.

URL:http://code.google.com/p/lilypond/issues/detail?id=2855

--
David Kastrup



Patchy has OK'd this, so I'd suggest pushing to staging or master direct, so 
I can see what GUB makes of it in the morning.  If you push to staging, I'll 
run patchy-staging if no-one else does to forward it to master.


--
Phil Holmes 



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

Re: GUB failure in parser.yy

[David Kastrup]

Phil Holmes m...@philholmes.net writes:

 - Original Message - 
 From: David Kastrup d...@gnu.org
 To: Phil Holmes m...@philholmes.net
 Cc: Devel lilypond-devel@gnu.org
 Sent: Saturday, September 22, 2012 6:38 PM
 Subject: Re: GUB failure in parser.yy


 Phil Holmes m...@philholmes.net writes:

 My preference _right now_ would be to remove the code that's causing
 the old version of Bison a problem.  To fix Gub, rebuild Gub and then
 rebuild lilypond would take considerable time which I don't have now.
 I'd like to get an updated version of lilypond out over this weekend.
 I'd be happy to discuss how to update Gub and then rebuild it starting
 next week.

 Trickier than expected, just changing lily/parser.yy was not enough.

 URL:http://code.google.com/p/lilypond/issues/detail?id=2855

 -- 
 David Kastrup


 Patchy has OK'd this, so I'd suggest pushing to staging or master
 direct, so I can see what GUB makes of it in the morning.  If you push
 to staging, I'll run patchy-staging if no-one else does to forward it
 to master.

Pushed to staging as
commit d15e5e49e148b253703cdcfad9b66a7fb29d404f
Author: David Kastrup d...@gnu.org
Date:   Sat Sep 22 19:36:25 2012 +0200

parser.yy: get along without %code Bison directive to reduce dependencies



-- 
David Kastrup


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

Re: GUB failure

[Carl Sorensen]

On 2/14/12 9:40 AM, Phil Holmes em...@philholmes.net wrote:

Not feeling too good today (cold) so I thought I'd do something not too
mentally taxing - another go at building GUB.  I've created a new user
just 
for this, and git cloned the GUB repo.  make bootstrap was fine, but make
lilyond ended with this.  Anyone any ideas?

ERROR: ld.so: object
'/home/gub/gub/target/tools/root/usr/lib/librestrict.so' from LD_PRELOAD
cannot be preloaded: ignored.
Command barfed: tar -C /home/gub/gub/target/darwin-x86/installer -zxf
/home/gub/gub/downloads/osx-lilypad/osx-lilypad-universal-0.6.tar.gz
Installer: class 'gub.installer.DarwinBundle'
Traceback (most recent call last):
  File bin/gib, line 185, in module
main ()
  File bin/gib, line 175, in main
build_installer (installer_obj)
  File bin/gib, line 141, in build_installer
available[s] ()
  File bin/../gub/installer.py, line 335, in create
''', locals ())
  File bin/../gub/context.py, line 226, in system
self.runner.system (cmd, env=dict, ignore_errors=ignore_errors)
  File bin/../gub/runner.py, line 105, in system
self.system_one (i, call_env, ignore_errors)
  File bin/../gub/runner.py, line 64, in system_one
ignore_errors=ignore_errors))
  File bin/../gub/runner.py, line 44, in _execute
return command.execute (self.logger)
  File bin/../gub/commands.py, line 75, in execute
ignore_errors=self.ignore_errors)
  File bin/../gub/loggedos.py, line 93, in system
raise misc.SystemFailed (m)
gub.misc.SystemFailed: Command barfed: tar -C
/home/gub/gub/target/darwin-x86/installer -zxf
/home/gub/gub/downloads/osx-lilypad/osx-lilypad-universal-0.6.tar.gz

Command barfed: /usr/bin/python
bin/gib --platform=darwin-x86 --branch=guile=
--branch=lilypond=git.sv.gnu.org--lilypond.git-master
lilypond
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 334, in build_source_packages
self.spec_build (spec_name)
  File bin/../gub/buildrunner.py, line 262, in spec_build
deferred_runner.execute_deferred_commands ()
  File bin/../gub/runner.py, line 167, in execute_deferred_commands
cmd.execute (self.logger)
  File bin/../gub/commands.py, line 75, in execute
ignore_errors=self.ignore_errors)
  File bin/../gub/loggedos.py, line 93, in system
raise misc.SystemFailed (m)
SystemFailed: Command barfed: /usr/bin/python
bin/gib --platform=darwin-x86 --branch=guile=
--branch=lilypond=git.sv.gnu.org--lilypond.git-master
lilypond

I also had a GUB failure over the weekend on two different lilydev
installs.  It was in darwin0x6, and python, but I'm not positive it was
exactly the same.  I didn't have time to follow up.

Thanks,

Carl


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

Re: GUB failure

[Graham Percival]

On Tue, Feb 14, 2012 at 04:40:54PM -, Phil Holmes wrote:
 ERROR: ld.so: object
 '/home/gub/gub/target/tools/root/usr/lib/librestrict.so' from
 LD_PRELOAD cannot be preloaded: ignored.

hmm.

 Command barfed: tar -C /home/gub/gub/target/darwin-x86/installer
 -zxf

What happens when you run this command manually?

- Graham

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

Re: GUB failure

[Phil Holmes]

- Original Message - 
From: Graham Percival gra...@percival-music.ca

To: Phil Holmes em...@philholmes.net
Cc: Devel lilypond-devel@gnu.org
Sent: Tuesday, February 14, 2012 6:26 PM
Subject: Re: GUB failure



On Tue, Feb 14, 2012 at 04:40:54PM -, Phil Holmes wrote:

ERROR: ld.so: object
'/home/gub/gub/target/tools/root/usr/lib/librestrict.so' from
LD_PRELOAD cannot be preloaded: ignored.


hmm.


Command barfed: tar -C /home/gub/gub/target/darwin-x86/installer
-zxf


What happens when you run this command manually?

- Graham



It runs fine.

--
Phil Holmes



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