|
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#L702Ok, 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.20git 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.gitYou 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
[Prev in Thread] | Current Thread | [Next in Thread] |