lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.20 plans.


From: Phil Holmes
Subject: Re: 2.20 plans.
Date: Tue, 30 Oct 2018 11:16:09 -0000



--
Phil Holmes


----- Original Message ----- From: "Federico Bruni" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: <address@hidden>
Sent: Tuesday, October 30, 2018 7:19 AM
Subject: Re: 2.20 plans.




Il giorno lun 29 ott 2018 alle 17:13, David Kastrup <address@hidden> ha scritto:
Federico Bruni <address@hidden> writes:

 Il giorno mar 16 ott 2018 alle 22:11, David Kastrup <address@hidden> ha
 scritto:
 "Phil Holmes" <address@hidden> writes:

  I've been trying a GUB build today.  It's failed rather strangely.
 At
  first I got:

  Command barfed: cd /home/gub/NewGub/gub/downloads/lilypond/git &&
 git
  fetch git://git.sv.gnu.org/lilypond.git
  stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20

  Tail of log/gub.log >>>>>>>>
  *** Stage: download (lilypond, darwin-x86)
  invoking cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch
  git://git.sv.gnu.org/lilypond.git
  stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20
  fatal: Unable to look up git.sv.gnu.org (port 9418) (Name or service
  not known)
  Command barfed: cd /home/gub/NewGub/gub/downloads/lilypond/git &&
 git
  fetch git://git.sv.gnu.org/lilypond.git
  stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20


  I thought that might be down to a network problem, so I tried the
  network and it looked OK so I ran the make again and this time I
 got:


  Tail of target/freebsd-x86/log/lilypond.log >>>>>>>>
  building package: freebsd-x86::lilypond
  *** Stage: download (lilypond, freebsd-x86)
  *** Stage: untar (lilypond, freebsd-x86)
  invoking cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch
  git://git.sv.gnu.org/lilypond.git
  stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20
  <<<<<<<< Tail of target/freebsd-x86/log/lilypond.log

  Traceback (most recent call last):
  File "bin/gub", line 233, in exceptional_build
  build (settings, options, files)
  File "bin/gub", line 229, in build
  b.build_source_packages (names)
  File "bin/../gub/buildrunner.py", line 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 48, in execute
  buildspec.source.update_workdir (buildspec.expand ('%(srcdir)s'))
  File "bin/../gub/repository.py", line 699, in update_workdir
  self._update_workdir_shallow (destdir)
  File "bin/../gub/repository.py", line 707, in
 _update_workdir_shallow
  barf
  NameError: global name 'barf' is not defined


  Any thoughts of where to go from here?

 "barf" sounds like an intentionally undefined function, "called" in
 order to get a backtrace.

 When I learnt programming, long long ago in the time of punch cards,
 my
 mentor used "CALL HUGO" for this purpose.  Indeed this triggered a
 _runtime_ error on the Fortran 77 compiler of the Cyber 175.

 I guess this is the same trick, just for Python.  So now we have a
 backtrace.  We just need to figure out what reason "barf" is getting
 called for.  What's in line 707 of repository.py ?


 git head is invalid?

    def _update_workdir_shallow (self, destdir):
        branch = self.branch # branch is empty?
        branch = 'master'
        HEAD = self.checksum ()
        if HEAD == 'invalid':
            barf

 from https://github.com/gperciva/gub/blob/master/gub/repository.py#L702

Ok, so where do we go from here?  This sounds like Phil has set
something up wrong.  Missing environment variables or something?


I know that Phil is using the same VM which has always worked so far. I doubt that there may be something wrong with his setup. I don't understand what an invalid HEAD might mean here, but I think that the network problem he had before the "barf" error is a good candidate.

Phil, do you see anything strange if you do the following?

cd target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20
 git status


I'm currently stuck here and cannot reproduce your error:
https://github.com/gperciva/gub/pull/6#issuecomment-431063463


I'll take a blind guess and suggest (for Phil):

1. run 'make lily-clean' and try again 'make lilypond'

But this will clean only the target of the platform you are building on (linux-x86 in my case) and not all the crossbuilds (as freebsd-x86):

address@hidden:~/gub$ make lily-clean
make -f lilypond.make lily-clean
**** lily-clean rule
make[1]: ingresso nella directory "/home/dev/gub"
rm -rf target/linux-x86/*/lilypond-git.sv.gnu.org--lilypond.git-master*
make[1]: uscita dalla directory "/home/dev/gub"

address@hidden:~/gub$ find target/ -name *lilypond-git.sv.gnu.org*
target/freebsd-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20
target/freebsd-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master
target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20
target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master


So I would 'rm -r target/freebsd-x86' and try again.



2. Can you build the master branch? If the problem is only with stable/2.20 you may try to change the version in lilypond.make:

LILYPOND_BRANCH=master
BUILDSCRIPTS=scripts/build
#BUILDSCRIPTS=buildscripts
# LILYPOND_BRANCH=stable/2.10
LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git

You can see above that stable/2.10 is commented. Perhaps it helped someone in the past?

HTH
Federico


Something of a hiatus at this end because I was unexpectedly called up to perform in a production of The Gondoliers singing Luiz at 2 weeks' notice. It was last week and I'm still a bit weary.

I think the best bet might be simply to start a new Gub instance on my build computer. To date I've used a VM, but since the machine is now running a 32 bit version of Ubuntu, I see no reason not to run it on the machine itself. I'll start this up later in the week.

--
Phil Holmes



reply via email to

[Prev in Thread] Current Thread [Next in Thread]