lilypond-devel
[Top][All Lists]
Advanced

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

Re: Stable release.


From: Phil Holmes
Subject: Re: Stable release.
Date: Tue, 26 Jun 2012 10:27:18 +0100

----- Original Message ----- From: "David Kastrup" <address@hidden>
To: <address@hidden>
Sent: Tuesday, June 26, 2012 10:02 AM
Subject: Re: Stable release.


David Kastrup <address@hidden> writes:

David Kastrup <address@hidden> writes:

Graham Percival <address@hidden> writes:

On Tue, Jun 26, 2012 at 07:33:12AM +0200, David Kastrup wrote:
My proposal was just about a release addressing bit rot, namely just
making sure that the equivalent of the existing release 2.14.2 can be
compiled (with no regressions due to the recompilation) on current
systems that insist on not using precompiled binaries from us (which is
quite sensible for distributing GPLed software).

Assuming that this is a 10-minute job, put stuff in the
stable/2.14 git branch, just in case somebody grabs the source
from git tarball.

It's more than 10 minutes since I have to through
hide-and-seek-and-recompile-and-check a few times.  But I don't think it
will take me longer than a few hours.  The two compiler bug fixes should
be reasonably easy to find again, and the C++ language issue should
resurface through attempting to compile, and then be traceable via git
blame.

Oh, and it might be that I misremembered and this C++ language issue was
actually in 2.12.  In that case, the only worry would be compiler bugs
that are likely already fixed in the mainstream distros (they tend to
pick up compiler bugfixes before the actual GCC releases).  It would
still be nice to have versions compiling under vanilla GCC 4.6.[0123]
and 4.7.0, but it would not be quite the disaster scenario I had in mind
when writing the original posting.

Whatever.  I am compiling now and seeing how far the unmodified source
gets me.

Ok, now I am amused.  make test of the unmodified 2.14 release branch in
a fresh directory yields

Processing `./01/lily-a2a4d578.ly'
Parsing...
Renaming input to: `lyric-combine-derived-voice.ly'
error: program too old: 2.14.2 (file requires: 2.14.3)
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
Writing header field `texidoc' to `./01/lily-a2a4d578.texidoc'...
Writing ./01/lily-a2a4d578-1.signature
Layout output to `./01/lily-a2a4d578.eps'...
Layout output to `./01/lily-a2a4d578-1.eps'...
Writing ./01/lily-a2a4d578-systems.texi...
Writing ./01/lily-a2a4d578-systems.tex...
Writing ./01/lily-a2a4d578-systems.count...
Writing timing to 01/lily-a2a4d578.profile...

The following commit _not_ contained in 2.14.2 is responsible for that:

commit c20806e357fbadeaa77ae8c51e5282cc2b6aec4a (HEAD, origin/2.14, 2.14)
Author: Reinhold Kainhofer <address@hidden>
Date:   Sat Jul 2 13:14:34 2011 +0200

   Fix Issue 770: Lyrics attached to a voice-derived context are off by 1

Now this patch has never been distributed as part of a release.  It was
apparently intended as a backport.  I am tempted removing it.

As far as I can see it's in 2.15 - both changed files are certainly there on my repo. It looks like the error is simply in a version statement in lyric-combine-derived-voice.ly - 'error: program too old: 2.14.2 (file requires: 2.14.3)'. You'll need to bump the version anyway - 2.14.3 is a possible. Have you tried bumping it and recompiling?


--
Phil Holmes



reply via email to

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