Re: Stable release.

[David Kastrup]

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
    
    The Lyric_combine_music_iterator had an explicit check if the CreateContext
    event was really for a context of type "Voice". Unfortunately, that
    check fails if the lyrics are supposed to be attached to a CueVoice
    context (or some self-defined Voice-derived context!), because
    "CueVoice"!="Voice".
    
    Unfortunately, I don't know how to check whether a context "CVoice"
    (identified only by a the context type string; we don't have any
    Context* object!) is an alias for Voice. If we had the Context* object,
    we could use is_alias, but we only have the string "CVoice" and need to
    check if a context of that type is an alias for "Voice".
    
    However, I don't think that check is necessary at all. It simply prevents
    find_voice from being called in cases when no Voice is generated (and thus
    no new context to possibly attach the lyrics to). If that check is removed,
    find_voice will also be called for any other context created while
    waiting for a voice to attach the lyrics to, but it will not find an
    appropriate voice anyway.
    
    Update version of regtest for backport


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

-- 
David Kastrup