Re: Today's GUB failure

[Phil Holmes]

Doh.  Thanks, as ever.

It then failed trying to access https://pkg-config.freedesktop.org/  which 
appears to be off the air at present.  I found an alternative at fossies.org 
and updated sources.py to use this location.  It now gives me:


Tail of target/tools/log/fontforge.log >>>>>>>>
checking Build with LibUniNamesList Unicode support?... configure: error: in 
`/home/gub/NewGub/gub/target/tools/build/fontforge-20190801':
configure: error: You may provide option ˋ--without-libuninameslistˋ to 
build without this recommended feature

See `config.log' for more details
Command barfed: cd 
/home/gub/NewGub/gub/target/tools/build/fontforge-20190801 && chmod +x 
/home/gub/NewGub/gub/target/tools/src/fontforge-20190801/configure && sh 
/home/gub/NewGub/gub/target/tools/src/fontforge-20190801/configure --prefix=/home/gub/NewGub/gub/target/tools/root/usr 
--enable-shared --enable-static --disable-silent-rules --without-cairo --without-x 
--enable-python-scripting=3 
CFLAGS=-I/home/gub/NewGub/gub/target/tools/root/usr/include 
LDFLAGS='-L/home/gub/NewGub/gub/target/tools/root/usr/lib -Wl,-rpath -Wl,\$$ORIGIN/../lib 
-Wl,-rpath -Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib '





--
Phil Holmes


- Original Message - 
From: "Jonas Hahnfeld" 

To: "Phil Holmes" ; "Devel" 
Sent: Sunday, April 26, 2020 12:18 PM
Subject: Re: Today's GUB failure

Re: Today's GUB failure

[Jonas Hahnfeld]

Am Sonntag, den 26.04.2020, 11:25 +0100 schrieb Phil Holmes:
> Can anyone help?  I'm getting this
> 
> /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py
>  
> line: 2 Undefined variable: import
> make[1]: *** [out/emmentaler-11.svg] Error 1
> make[1]: *** Waiting for unfinished jobs
> Making mf/out/emmentaler-14.svg
> Copyright (c) 2000-2011 by George Williams.
> Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
> Library based on sources from 13:48 GMT 22-Feb-2011.
> /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py
>  
> line: 2 Undefined variable: import
> make[1]: *** [out/emmentaler-13.svg] Error 1
> Copyright (c) 2000-2011 by George Williams.
> Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
> Library based on sources from 13:48 GMT 22-Feb-2011.
> /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py
>  
> line: 2 Undefined variable: import
> make[1]: *** [out/emmentaler-14.svg] Error 1
> Copyright (c) 2000-2011 by George Williams.
> Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
> Library based on sources from 13:48 GMT 22-Feb-2011.
> Copyright (c) 2000-2011 by George Williams.
> Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
> Library based on sources from 13:48 GMT 22-Feb-2011.
> Copyright (c) 2000-2011 by George Williams.
> Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
> Library based on sources from 13:48 GMT 22-Feb-2011.
> make: *** [all] Error 2
> Command barfed: cd 
> /home/gub/NewGub/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable
>  
> && make -j16 TARGET_PYTHON=/usr/bin/python3

You have to pull what you merge 
https://github.com/gperciva/gub/pull/72


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

Today's GUB failure

[Phil Holmes]

Can anyone help?  I'm getting this

/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py 
line: 2 Undefined variable: import

make[1]: *** [out/emmentaler-11.svg] Error 1
make[1]: *** Waiting for unfinished jobs
Making mf/out/emmentaler-14.svg
Copyright (c) 2000-2011 by George Williams.
Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
Library based on sources from 13:48 GMT 22-Feb-2011.
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py 
line: 2 Undefined variable: import

make[1]: *** [out/emmentaler-13.svg] Error 1
Copyright (c) 2000-2011 by George Williams.
Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
Library based on sources from 13:48 GMT 22-Feb-2011.
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py 
line: 2 Undefined variable: import

make[1]: *** [out/emmentaler-14.svg] Error 1
Copyright (c) 2000-2011 by George Williams.
Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
Library based on sources from 13:48 GMT 22-Feb-2011.
Copyright (c) 2000-2011 by George Williams.
Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
Library based on sources from 13:48 GMT 22-Feb-2011.
Copyright (c) 2000-2011 by George Williams.
Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D.
Library based on sources from 13:48 GMT 22-Feb-2011.
make: *** [all] Error 2
Command barfed: cd 
/home/gub/NewGub/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable 
&& make -j16 TARGET_PYTHON=/usr/bin/python3




--
Phil Holmes

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

GUB failure

[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.  Otherwise I'll have to upgrade to Ubuntu 16, which I was 
avoiding while I still had a working installation.


--
Phil Holmes

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

Gub failure

[Phil Holmes]

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?


___
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" <m...@philholmes.net>

To: <lilypond-devel@gnu.org>
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

Gub failure

[Phil Holmes]

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

GUB failure

[Phil Holmes]

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?


___
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: Resending: further GUB failure

[Phil Holmes]

[snip all]

Thanks.  GUB is now built and will be uploaded this evening.

--
Phil Holmes

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

Re: Resending: further GUB failure

[Phil Holmes]

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

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


I consider it a bad idea to have those changes in a release without
having them in master.  I think what you want to do here is to back out
those changes again since they were required as a consequence of issue
4550 which has been reverted.  You should be able to do this using

git checkout release/unstable
git reset --hard 314336b

and then start over with

git merge origin/master
git cherry-pick c3eeea3dd # This is the release news

--
David Kastrup



What I was planning on doing and have now tried, was to reset 
release/unstable back to Dan's commit 
59a6d1a06432fc0ca88c3023c646182f389ec1b5 and then repeat the merge of 
origin/master and the edits to VERSION and news, and then push this back to 
release/unstable.


This is rejected with a note that it will lose history and therefore can't 
be fast-forwarded.  I presume the history that will be lost were the 
attempts to fix the GUB compile?  If so, I presume I should force the push? 
If so, could you remind me of the syntax?


Thanks.

--
Phil Holmes 



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

Re: Resending: further GUB failure

[David Kastrup]

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

 - Original Message - 
 From: David Kastrup d...@gnu.org
 To: Phil Holmes m...@philholmes.net

 I consider it a bad idea to have those changes in a release without
 having them in master.  I think what you want to do here is to back out
 those changes again since they were required as a consequence of issue
 4550 which has been reverted.  You should be able to do this using

 git checkout release/unstable
 git reset --hard 314336b

 and then start over with

 git merge origin/master
 git cherry-pick c3eeea3dd # This is the release news

 -- 
 David Kastrup


 What I was planning on doing and have now tried, was to reset
 release/unstable back to Dan's commit
 59a6d1a06432fc0ca88c3023c646182f389ec1b5 and then repeat the merge of
 origin/master and the edits to VERSION and news, and then push this
 back to release/unstable.

 This is rejected with a note that it will lose history and therefore
 can't be fast-forwarded.  I presume the history that will be lost were
 the attempts to fix the GUB compile?

Yup.

 If so, I presume I should force the push? If so, could you remind me
 of the syntax?

Uh, followup mail to the mail you quoted?

Phil, did you see the following message?  I'm asking because
origin/release/unstable still looks like containing the additional
commits not in master.  While that does not necessarily mean that your
own release/unstable does, it is somewhat worrisome.

If you have problems _pushing_ your own release/unstable because the
current origin/release/unstable is not a proper ancestor of it, you can
delete origin/release/unstable with

git push origin :refs/heads/release/unstable

and then overwrite with your local release/unstable (assuming that the
_branch_ is where you want it) using

git push origin release/unstable:refs/heads/release/unstable

Executive summary: just do

git push origin :refs/heads/release/unstable

and then repeat whatever push was rejected, but make sure to write the
whole :refs/heads/release/unstable incantation as the target of the push
since Git will not be able to deduce it correctly once you deleted the
branch on the server.

-- 
David Kastrup

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

Re: Different GUB failure

[Masamichi HOSODA]

 The Darwin-PPC compile now proceeds fine following the revert.  I'm
 now
 getting a failure to build the daja-vu fonts: it looks like the font
 file
 has not been downloaded:

 invoking tar -C
 /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
 --strip-component=1 -v -j -xf
 --/home/gub/NewGub/gub/downloads/fonts-dejavu
 /dejavu-fonts-ttf-2.35.tar.bz2
 tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
 ttf-2.35.tar.bz2: Cannot open: No such file or directory

 I can confirm that that directory is empty.

 I was able to fix the dejavu font problem with Masamichi's suggestion
 of

 $ bin/gub --fresh tools::fonts-dejavu

 However, the build now fails with the same error with the libertine
 font, which has not been downloaded.  I could potentially fix that by
 downloading the font manually, and would probably need to do this for
 all the other new fonts.

 But shouldn't this happen automatically as part of the GUB build?

 If I understand correctly, GUB downloads automatically, ofcourse.
 To build LilyPond, what command do you use?
 Is it following?

 $ make LILYPOND_BRANCH=release/unstable lilypond
 
 That's the command I use, but with the output redirected to a text
 file.
 
 I suspect something like download site or network temporarily
 problems.
 
 I don't think so: if GUB tries a download and it fails, it usually
 stops at that point and can be restarted once the network/site is back
 or corrected. Looking at the output from the build, I see no attempt
 to download the font files.

You are right.
I've found a problem.

lilypond.make's doc and test-output uses offline mode.
So dependency files are not downloaded.

I've made a patch and send pull request.
https://github.com/gperciva/gub/pull/19

Would you merge it?
And, would you update your GUB's local working tree?

$ 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: Different GUB failure

[Phil Holmes]

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

To: m...@philholmes.net
Cc: lilypond-devel@gnu.org
Sent: Tuesday, August 25, 2015 3:04 PM
Subject: Re: Different GUB failure



The Darwin-PPC compile now proceeds fine following the revert.  I'm
now
getting a failure to build the daja-vu fonts: it looks like the font
file
has not been downloaded:

invoking tar -C
/home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
--strip-component=1 -v -j -xf
--/home/gub/NewGub/gub/downloads/fonts-dejavu
/dejavu-fonts-ttf-2.35.tar.bz2
tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
ttf-2.35.tar.bz2: Cannot open: No such file or directory

I can confirm that that directory is empty.


I was able to fix the dejavu font problem with Masamichi's suggestion
of

$ bin/gub --fresh tools::fonts-dejavu

However, the build now fails with the same error with the libertine
font, which has not been downloaded.  I could potentially fix that by
downloading the font manually, and would probably need to do this for
all the other new fonts.

But shouldn't this happen automatically as part of the GUB build?


If I understand correctly, GUB downloads automatically, ofcourse.
To build LilyPond, what command do you use?
Is it following?

$ make LILYPOND_BRANCH=release/unstable lilypond


That's the command I use, but with the output redirected to a text file.


I suspect something like download site or network temporarily problems.


I don't think so: if GUB tries a download and it fails, it usually stops at 
that point and can be restarted once the network/site is back or corrected. 
Looking at the output from the build, I see no attempt to download the font 
files.


--
Phil Holmes 



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

Re: Different GUB failure

[Phil Holmes]

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

To: m...@philholmes.net
Cc: lilypond-devel@gnu.org
Sent: Tuesday, August 25, 2015 3:39 PM
Subject: Re: Different GUB failure




You are right.
I've found a problem.

lilypond.make's doc and test-output uses offline mode.
So dependency files are not downloaded.

I've made a patch and send pull request.
https://github.com/gperciva/gub/pull/19

Would you merge it?


Done


And, would you update your GUB's local working tree?

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


Done.  The build is proceeding and the font files are downloading.

Once again, my grateful thanks for your help in keeping the LilyPond build 
system working, and allowing me to let users work with the latest versions.


--
Phil Holmes 



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

Re: Different GUB failure

[Masamichi HOSODA]

 The Darwin-PPC compile now proceeds fine following the revert.  I'm
 now
 getting a failure to build the daja-vu fonts: it looks like the font
 file
 has not been downloaded:

 invoking tar -C
 /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
 --strip-component=1 -v -j -xf
 --/home/gub/NewGub/gub/downloads/fonts-dejavu
 /dejavu-fonts-ttf-2.35.tar.bz2
 tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
 ttf-2.35.tar.bz2: Cannot open: No such file or directory

 I can confirm that that directory is empty.
 
 I was able to fix the dejavu font problem with Masamichi's suggestion
 of
 
 $ bin/gub --fresh tools::fonts-dejavu
 
 However, the build now fails with the same error with the libertine
 font, which has not been downloaded.  I could potentially fix that by
 downloading the font manually, and would probably need to do this for
 all the other new fonts.
 
 But shouldn't this happen automatically as part of the GUB build?

If I understand correctly, GUB downloads automatically, ofcourse.
To build LilyPond, what command do you use?
Is it following?

$ make LILYPOND_BRANCH=release/unstable lilypond

I suspect something like download site or network temporarily problems.

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

Re: Different GUB failure

[Phil Holmes]

Masamichi HOSODA trueroad at sea.plala.or.jp writes:

 
  The Darwin-PPC compile now proceeds fine following the revert.  I'm now
  getting a failure to build the daja-vu fonts: it looks like the font file
  has not been downloaded:
  
  invoking tar -C /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
  --strip-component=1 -v -j -xf /home/gub/NewGub/gub/downloads/fonts-dejavu
  /dejavu-fonts-ttf-2.35.tar.bz2
  tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
  ttf-2.35.tar.bz2: Cannot open: No such file or directory
  
  I can confirm that that directory is empty.
 
 I can download it now.
 Maybe it is some download mirror site problem.
 
 Would you try the following command?
 
 $ bin/gub --fresh tools::fonts-dejavu
 

I get this:

*** environment changed

#new# HTTP_PROXY=
unset HTTP_PROXY
#new# PATH=/home/gub/NewGub/gub/target/tools/root/usr/bin:/usr/local
/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local
/games
PATH=/home/gub/NewGub/gub/target/tools/root/usr/bin:/usr/local/bin:/usr
/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

*** press ^C in 10s or suffer a full rebuild..calculating dependencies

Tail of log/gub.log 
root: /home/gub/NewGub/gub/target/linux-x86/root
platform: linux-x86
calculating dependencies
making spec:  tools:fonts-dejavu
 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 170, in build
(names, specs) = gup.get_source_packages (settings, files)
  File bin/../gub/gup.py, line 539, in get_source_packages
topologically_sorted (todo, {}, name_to_dependencies_broker)
  File bin/../gub/gup.py, line 409, in topologically_sorted
recurse_stop_predicate)
  File bin/../gub/gup.py, line 389, in topologically_sorted_one
deps = dependency_getter (todo)
  File bin/../gub/gup.py, line 527, in name_to_dependencies_broker
name_to_dependencies_via_gub) (url)
  File bin/../gub/gup.py, line 479, in name_to_dependencies_via_gub
spec = dependency.Dependency (sets[platform], name, url).build ()
  File bin/../gub/dependency.py, line 155, in build
b = self._create_build ()
  File bin/../gub/dependency.py, line 107, in _create_build
source = repository.get_repository_proxy (dir, source, branch)
  File bin/../gub/repository.py, line 105, in get_repository
% locals ())
UnknownVcSystem: Cannot determine source: url=tools:fonts-dejavu,
dir=/home/gub/NewGub/gub/downloads/tools:fonts-dejavu



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

Re: Resending: further GUB failure

[David Kastrup]

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

 The Darwin-PPC compile now proceeds fine following the revert.  I'm now
 getting a failure to build the daja-vu fonts: it looks like the font file
 has not been downloaded:

 invoking tar -C /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
 --strip-component=1 -v -j -xf /home/gub/NewGub/gub/downloads/fonts-dejavu
 /dejavu-fonts-ttf-2.35.tar.bz2
 tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
 ttf-2.35.tar.bz2: Cannot open: No such file or directory

 I can confirm that that directory is empty.

Just a note: origin/release/unstable is currently _seriously_ diverged
from master because it contains additional commits shown as part of

git log origin/master..origin/release/unstable

namely

commit e10774768c04925c1d7e71b22f5d11a8c32c9df2
Author: Phil Holmes m...@philholmes.net
Date:   Sun Aug 23 16:14:17 2015 +0100

Further fix to Issue 4550 to fix GUB fail

commit ff8a88eaf999491e375e61780f633fabc2b02c1c
Author: Masamichi Hosoda truer...@trueroad.jp
Date:   Sun Aug 23 23:47:37 2015 +0900

Fix Issue 4550: Add std:: to isinf() and isnan()

gcc 4.9.x needs std:: to isinf() and isnan().


I consider it a bad idea to have those changes in a release without
having them in master.  I think what you want to do here is to back out
those changes again since they were required as a consequence of issue
4550 which has been reverted.  You should be able to do this using

git checkout release/unstable
git reset --hard 314336b

and then start over with

git merge origin/master
git cherry-pick c3eeea3dd # This is the release news

-- 
David Kastrup

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

Re: Different GUB failure

[Phil Holmes]

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

To: lilypond-devel@gnu.org
Sent: Monday, August 24, 2015 3:10 PM
Subject: Different GUB failure



The Darwin-PPC compile now proceeds fine following the revert.  I'm now
getting a failure to build the daja-vu fonts: it looks like the font file
has not been downloaded:

invoking tar -C /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
--strip-component=1 -v -j -xf /home/gub/NewGub/gub/downloads/fonts-dejavu
/dejavu-fonts-ttf-2.35.tar.bz2
tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
ttf-2.35.tar.bz2: Cannot open: No such file or directory

I can confirm that that directory is empty.


I was able to fix the dejavu font problem with Masamichi's suggestion of

$ bin/gub --fresh tools::fonts-dejavu

However, the build now fails with the same error with the libertine font, 
which has not been downloaded.  I could potentially fix that by downloading 
the font manually, and would probably need to do this for all the other new 
fonts.


But shouldn't this happen automatically as part of the GUB build?

--
Phil Holmes 



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

Different GUB failure

[Phil Holmes]

The Darwin-PPC compile now proceeds fine following the revert.  I'm now
getting a failure to build the daja-vu fonts: it looks like the font file
has not been downloaded:

invoking tar -C /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
--strip-component=1 -v -j -xf /home/gub/NewGub/gub/downloads/fonts-dejavu
/dejavu-fonts-ttf-2.35.tar.bz2
tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
ttf-2.35.tar.bz2: Cannot open: No such file or directory

I can confirm that that directory is empty.


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

Resending: further GUB failure

[Phil Holmes]

The Darwin-PPC compile now proceeds fine following the revert.  I'm now
getting a failure to build the daja-vu fonts: it looks like the font file
has not been downloaded:

invoking tar -C /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
--strip-component=1 -v -j -xf /home/gub/NewGub/gub/downloads/fonts-dejavu
/dejavu-fonts-ttf-2.35.tar.bz2
tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
ttf-2.35.tar.bz2: Cannot open: No such file or directory

I can confirm that that directory is empty.


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

Re: Different GUB failure

[Masamichi HOSODA]

 The Darwin-PPC compile now proceeds fine following the revert.  I'm now
 getting a failure to build the daja-vu fonts: it looks like the font file
 has not been downloaded:
 
 invoking tar -C /home/gub/NewGub/gub/target/tools/src/fonts-dejavu-2.35
 --strip-component=1 -v -j -xf /home/gub/NewGub/gub/downloads/fonts-dejavu
 /dejavu-fonts-ttf-2.35.tar.bz2
 tar (child): /home/gub/NewGub/gub/downloads/fonts-dejavu/dejavu-fonts-
 ttf-2.35.tar.bz2: Cannot open: No such file or directory
 
 I can confirm that that directory is empty.

I can download it now.
Maybe it is some download mirror site problem.

Would you try the following command?

$ bin/gub --fresh tools::fonts-dejavu

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

Re: Further GUB failure

[Dan Eble]

David wrote:
 isinf is supposed to be defined in cmath (without scoping) which is
 included by flower/include/offset.hh.  And of course this works on most
 platforms or we'd have gotten complaints already.

What’s your source?  http://en.cppreference.com/w/cpp/numeric/math/isinf shows 
that the isinf() provided by cmath is in the std namespace, and only since 2011.

 Dan, wasn't the idea of the patch to remove using std from the
 _include_ files where they'd mess with the namespace of arbitrary files
 including them?

That was the important part.  I went farther and removed it entirely because it 
is considered good practice to avoid using everything in the std namespace.

In issue 4550, I chose to write std::whatever() for many things even in *.cc 
files.  I did add “using std::whatever;” for container types because those are 
very frequently used in Lilypond and I didn’t want people to feel like I came 
in and trashed the joint.

 Wouldn't that mean that a good fix not defeating the
 original purpose of the patch would be to just put the respective using
 statement in the .cc files?

That’s probably the simplest option for those who are dealing with the problem. 
 If they can afford the time to be specific, e.g.

using std::isinf;
using std::isnan;
...

That would be better.  It would also make it easier for someone (I volunteer) 
to replace them later with in-loco std::whatever() to return to consistency 
with the style set in issue 4550.

I’m sorry my patch caused these problems!

Regards,
— 
Dan


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

Re: Further GUB failure

[David Kastrup]

Dan Eble d...@faithful.be writes:

 David wrote:
 isinf is supposed to be defined in cmath (without scoping) which is
 included by flower/include/offset.hh.  And of course this works on most
 platforms or we'd have gotten complaints already.

 What’s your source?

I tried interpreting the last draft C++11 standard and did not really
find anything conclusive in there.  So I interpreted this as meaning
non-scoped.

 http://en.cppreference.com/w/cpp/numeric/math/isinf shows that the
 isinf() provided by cmath is in the std namespace, and only since
 2011.

Oh great.

 Dan, wasn't the idea of the patch to remove using std from the
 _include_ files where they'd mess with the namespace of arbitrary files
 including them?

 That was the important part.  I went farther and removed it entirely
 because it is considered good practice to avoid using everything in
 the std namespace.

I reverted both commits belonging to issue 4550.  I have no idea whether
just one would have been necessary but since we didn't test them in
isolation, that seemed like the safest course for now.

-- 
David Kastrup

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

Re: Further GUB failure

[David Kastrup]

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

 - Original Message - 
 From: David Kastrup d...@gnu.org
 To: Phil Holmes m...@philholmes.net
 Cc: lilypond-devel@gnu.org
 Sent: Sunday, August 23, 2015 4:00 PM
 Subject: Re: Further GUB failure


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

 I'm now getting this error:

 /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]))
  ^

 It looks like the compiler cannot find isinf, and possibly this
 patch is guilty:

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

 isinf is supposed to be defined in cmath (without scoping) which is
 included by flower/include/offset.hh.  And of course this works on most
 platforms or we'd have gotten complaints already.

 Now darwin-ppc is an obsolete platform and consequently our cross
 compiler/library is likely not all that up-to-date.  I fear this is
 likely a compiler/library bug and it will likely be rather tough to
 figure out an appropriate workaround when the only available test is
 running GUB by a volunteer without much knowledge about either GUB's
 internal workings or Darwin-PPC.

 Would it be feasible to run on a version where the patch for issue 4550
 has been reverted?  We might cheat our way through in that manner (this
 is not likely to have runtime effects) but short of a volunteer to
 figure out what's going wrong here in detail, it might mean that maybe
 it's time to retire Darwin-PPC.  We can still bring it back in once
 somebody volunteers to fix this and possibly future problems.

 -- 
 David Kastrup


 I applied Hosoda-San's patch and the problem moved to lookup.cc.
 Fixed that and got a fail with another *.cc.  It would seem the best
 fix would be for someone with the skills in Unix command line to
 replace all instances of isinf and isnan (any others?) with the
 std::isnan prefix?

 It only takes a couple of minutes for the build to fail, so
 experimenting to get rid of the bug is not too wearisome.

Dan, wasn't the idea of the patch to remove using std from the
_include_ files where they'd mess with the namespace of arbitrary files
including them?  Wouldn't that mean that a good fix not defeating the
original purpose of the patch would be to just put the respective using
statement in the .cc files?

What's your preferred fix?

-- 
David Kastrup

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

Re: Further GUB failure

[Masamichi HOSODA]

 I'm now getting this error:
 
 /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]))
  ^
 
 It looks like the compiler cannot find isinf, and possibly this patch is 
 guilty:
 
 http://code.google.com/p/lilypond/issues/detail?id=4550

I've reproduced it on my Cygwin64 gcc-4.9.3 environment.
Attached patch can be fixed it.
From 5d4af6d8ad286dce49e65af14f8c008f59dd36d5 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Sun, 23 Aug 2015 23:47:37 +0900
Subject: [PATCH] Fix Issue 4550: Add std:: to isinf() and isnan()

gcc 4.9.x needs std:: to isinf() and isnan().
---
 flower/offset.cc | 16 
 lily/bezier.cc   |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/flower/offset.cc b/flower/offset.cc
index 2fc9bf9..8c476ee 100644
--- a/flower/offset.cc
+++ b/flower/offset.cc
@@ -40,7 +40,7 @@ Offset
 complex_multiply (Offset z1, Offset z2)
 {
   Offset z;
-  if (!isinf (z2[Y_AXIS]))
+  if (!std::isinf (z2[Y_AXIS]))
 {
   z[X_AXIS] = z1[X_AXIS] * z2[X_AXIS] - z1[Y_AXIS] * z2[Y_AXIS];
   z[Y_AXIS] = z1[X_AXIS] * z2[Y_AXIS] + z1[Y_AXIS] * z2[X_AXIS];
@@ -98,22 +98,22 @@ Offset::length () const
 bool
 Offset::is_sane () const
 {
-  return !isnan (coordinate_a_[X_AXIS])
-  !isnan (coordinate_a_ [Y_AXIS])
-  !isinf (coordinate_a_[X_AXIS])
-  !isinf (coordinate_a_[Y_AXIS]);
+  return !std::isnan (coordinate_a_[X_AXIS])
+  !std::isnan (coordinate_a_ [Y_AXIS])
+  !std::isinf (coordinate_a_[X_AXIS])
+  !std::isinf (coordinate_a_[Y_AXIS]);
 }
 
 Offset
 Offset::direction () const
 {
   Offset d = *this;
-  if (isinf (d[X_AXIS]))
+  if (std::isinf (d[X_AXIS]))
 {
-  if (!isinf (d[Y_AXIS]))
+  if (!std::isinf (d[Y_AXIS]))
 return Offset ((d[X_AXIS]  0.0 ? 1.0 : -1.0), 0.0);
 }
-  else if (isinf (d[Y_AXIS]))
+  else if (std::isinf (d[Y_AXIS]))
 return Offset (0.0, (d[Y_AXIS]  0.0 ? 1.0 : -1.0));
   else if (d[X_AXIS] == 0.0  d[Y_AXIS] == 0.0)
 return d;
diff --git a/lily/bezier.cc b/lily/bezier.cc
index e2c099b..daa2673 100644
--- a/lily/bezier.cc
+++ b/lily/bezier.cc
@@ -342,8 +342,8 @@ void
 Bezier::assert_sanity () const
 {
   for (int i = 0; i  CONTROL_COUNT; i++)
-assert (!isnan (control_[i].length ())
- !isinf (control_[i].length ()));
+assert (!std::isnan (control_[i].length ())
+ !std::isinf (control_[i].length ()));
 }
 
 void
-- 
2.4.5

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

Re: Further 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, August 23, 2015 4:00 PM
Subject: Re: Further GUB failure



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


I'm now getting this error:

/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]))
 ^

It looks like the compiler cannot find isinf, and possibly this patch is 
guilty:


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


isinf is supposed to be defined in cmath (without scoping) which is
included by flower/include/offset.hh.  And of course this works on most
platforms or we'd have gotten complaints already.

Now darwin-ppc is an obsolete platform and consequently our cross
compiler/library is likely not all that up-to-date.  I fear this is
likely a compiler/library bug and it will likely be rather tough to
figure out an appropriate workaround when the only available test is
running GUB by a volunteer without much knowledge about either GUB's
internal workings or Darwin-PPC.

Would it be feasible to run on a version where the patch for issue 4550
has been reverted?  We might cheat our way through in that manner (this
is not likely to have runtime effects) but short of a volunteer to
figure out what's going wrong here in detail, it might mean that maybe
it's time to retire Darwin-PPC.  We can still bring it back in once
somebody volunteers to fix this and possibly future problems.

--
David Kastrup



I applied Hosoda-San's patch and the problem moved to lookup.cc.  Fixed that 
and got a fail with another *.cc.  It would seem the best fix would be for 
someone with the skills in Unix command line to replace all instances of 
isinf and isnan (any others?) with the std::isnan prefix?


It only takes a couple of minutes for the build to fail, so experimenting to 
get rid of the bug is not too wearisome.


--
Phil Holmes 



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

Further GUB failure

[Phil Holmes]

I'm now getting this error:

/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]))
 ^

It looks like the compiler cannot find isinf, and possibly this patch is guilty:

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


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

Re: Further GUB failure

[David Kastrup]

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

 I'm now getting this error:

 /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]))
  ^

 It looks like the compiler cannot find isinf, and possibly this patch is 
 guilty:

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

isinf is supposed to be defined in cmath (without scoping) which is
included by flower/include/offset.hh.  And of course this works on most
platforms or we'd have gotten complaints already.

Now darwin-ppc is an obsolete platform and consequently our cross
compiler/library is likely not all that up-to-date.  I fear this is
likely a compiler/library bug and it will likely be rather tough to
figure out an appropriate workaround when the only available test is
running GUB by a volunteer without much knowledge about either GUB's
internal workings or Darwin-PPC.

Would it be feasible to run on a version where the patch for issue 4550
has been reverted?  We might cheat our way through in that manner (this
is not likely to have runtime effects) but short of a volunteer to
figure out what's going wrong here in detail, it might mean that maybe
it's time to retire Darwin-PPC.  We can still bring it back in once
somebody volunteers to fix this and possibly future problems.

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

GUB failure

[Phil Holmes]

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?


___
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

GUB failure in parser.yy

[Phil Holmes]

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.

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

GUB failure

[Phil Holmes]

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


--
Phil Holmes



___
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

GUB failure in tools::gzip

[Neil Puttock]

Hi Jan,

I'm getting a build failure at the compile stage for gzip which is
caused by a naming conflict with glibc's futimens () function:

In file included from ./sys/stat.h:27,
 from ./fcntl.h:26,
 from
/home/neil/gub/target/tools/src/gzip-1.3.12/lib/utimens.c:29:
///usr/include/sys/stat.h:370: error: conflicting types for ‘futimens’
/home/neil/gub/target/tools/src/gzip-1.3.12/lib/utimens.h:2: error:
previous declaration of ‘futimens’ was here
/home/neil/gub/target/tools/src/gzip-1.3.12/lib/utimens.c: In function
‘utimens’:
/home/neil/gub/target/tools/src/gzip-1.3.12/lib/utimens.c:188:
warning: passing argument 2 of ‘futimens’ from incompatible pointer
type
/home/neil/gub/target/tools/src/gzip-1.3.12/lib/utimens.c:188: error:
too many arguments to function ‘futimens’
make[2]: *** [utimens.o] Error 1
make[2]: Leaving directory `/home/neil/gub/target/tools/build/gzip-1.3.12/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/neil/gub/target/tools/build/gzip-1.3.12/lib'
make: *** [all-recursive] Error 1

I've attached a patch which renames gzip's version.

Regards,
Neil
From 902730e6d37a16a822a0d5fc7d7bf353e302 Mon Sep 17 00:00:00 2001
From: Neil Puttock n.putt...@gmail.com
Date: Fri, 21 Aug 2009 00:37:08 +0100
Subject: [PATCH] gzip: rename futimens () to prevent glibc conflict.

---
 gub/specs/gzip.py  |1 +
 patches/gzip-1.3.12-glibc-compat.patch |   36 
 2 files changed, 37 insertions(+), 0 deletions(-)
 create mode 100644 patches/gzip-1.3.12-glibc-compat.patch

diff --git a/gub/specs/gzip.py b/gub/specs/gzip.py
index b0d870e..49abd2c 100644
--- a/gub/specs/gzip.py
+++ b/gub/specs/gzip.py
@@ -4,3 +4,4 @@ if 'BOOTSTRAP' in os.environ.keys (): from gub import target as tools
 
 class Gzip__tools (tools.AutoBuild):
 source = 'http://ftp.gnu.org/pub/gnu/gzip/gzip-1.3.12.tar.gz'
+patches = ['gzip-1.3.12-glibc-compat.patch']
diff --git a/patches/gzip-1.3.12-glibc-compat.patch b/patches/gzip-1.3.12-glibc-compat.patch
new file mode 100644
index 000..37d9ddb
--- /dev/null
+++ b/patches/gzip-1.3.12-glibc-compat.patch
@@ -0,0 +1,36 @@
+--- gzip-1.3.12/gzip.c	2007-03-20 05:09:51.0 +
 gzip-1.3.12/gzip.c	2009-08-21 00:13:55.0 +0100
+@@ -1637,7 +1637,7 @@
+ 	}
+   }
+ 
+-if (futimens (ofd, ofname, timespec) != 0)
++if (gz_futimens (ofd, ofname, timespec) != 0)
+   {
+ 	int e = errno;
+ 	WARN ((stderr, %s: , program_name));
+--- gzip-1.3.12/lib/utimens.c	2007-01-18 08:33:34.0 +
 gzip-1.3.12/lib/utimens.c	2009-08-21 00:13:55.0 +0100
+@@ -75,7 +75,7 @@
+Return 0 on success, -1 (setting errno) on failure.  */
+ 
+ int
+-futimens (int fd ATTRIBUTE_UNUSED,
++gz_futimens (int fd ATTRIBUTE_UNUSED,
+ 	  char const *file, struct timespec const timespec[2])
+ {
+   /* Some Linux-based NFS clients are buggy, and mishandle time stamps
+@@ -185,5 +185,5 @@
+ int
+ utimens (char const *file, struct timespec const timespec[2])
+ {
+-  return futimens (-1, file, timespec);
++  return gz_futimens (-1, file, timespec);
+ }
+--- gzip-1.3.12/lib/utimens.h	2007-02-23 18:25:21.0 +
 gzip-1.3.12/lib/utimens.h	2009-08-21 00:13:55.0 +0100
+@@ -1,3 +1,3 @@
+ #include time.h
+-int futimens (int, char const *, struct timespec const [2]);
++int gz_futimens (int, char const *, struct timespec const [2]);
+ int utimens (char const *, struct timespec const [2]);
-- 
1.6.0.4

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

gub failure

[Erik Sandberg]

hi,

make download fails, giving a 404 on
http://lilypond.org/download/v2.11/

-- 
Erik


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