Can't run 2.4.10 (was: GnuCash 2.4.10 released)

[John Ralls]

On Feb 11, 2012, at 9:13 AM, Geert Janssens wrote:

> Op zaterdag 11 februari 2012 08:50:24 schreef John Ralls:
>> On Feb 10, 2012, at 11:11 AM, John Ralls wrote:
>>> On Feb 10, 2012, at 7:02 AM, Geert Janssens wrote:
>>>> Op donderdag 9 februari 2012 08:43:31 schreef John Ralls:
>>>>> On Feb 9, 2012, at 8:27 AM, Geert Janssens wrote:
>>>>>> Op donderdag 9 februari 2012 17:01:22 schreef Geert Janssens:
>>>>>>> Op woensdag 8 februari 2012 18:02:36 schreef John Ralls:
>>>>>>>> I just looked, and there was a snap re-release (2.24.10) on
>>>>>>>> Monday,
>>>>>>>> and
>>>>>>>> the Win32 binaries are up at ftp.gnome.org. After testing that
>>>>>>>> it
>>>>>>>> builds, I committed a change to the GC 2.4 branch, so you and
>>>>>>>> Geert
>>>>>>>> can
>>>>>>>> try tomorrow's nightly.
>>>>>>> 
>>>>>>> I have just ran a successful test with the latest nightly. It
>>>>>>> works
>>>>>>> fine on my 16bit remote desktop connection. Yay !
>>>>>>> 
>>>>>>> Geert
>>>>>> 
>>>>>> Just wondering:
>>>>>> - this one fix probably doesn't warrant a new release, does it ?
>>>>>> - with this fix, it looks like the 2.4 Windows build is fully
>>>>>> working
>>>>>> with the newer gtk. Have all the required fixes been
>>>>>> forward-ported to
>>>>>> trunk already ?
>>>>> 
>>>>> No, I don't think so.  What would the buildbot do if I change
>>>>> defaults.sh on the 2.4.10 tag? Or make a new 2.4.10-1 tag and
>>>>> change defaults.sh there?>> 
>>>> From what I read in the build_tags.sh script (which you can find in
>>>> packaging/win32), both may result in a new tag build for 2.4.10,
>>>> though I'm not really sure.
>>>> 
>>>> If changing defaults.sh in the 2.4.10 directory would increment the
>>>> revision number on the directory itself, that would trigger a new
>>>> build.
>>>> 
>>>> Tagging with 2.4.10-1 creates a new tag, which should also trigger a
>>>> build. I think this approach would be cleaner than to modify an
>>>> officially released tag.
>>> 
>>> OK, I just tagged r21977 as 2.4.10-1, and I'll replace the download on
>>> SF and uptdate the website pointers tomorrow morning after it builds.
>> And it tried to build and failed in MinGW. Can someone with shell access
>> have a look and relaunch it?
>> 
> I was just looking into it.
> 
> The cause of the failure confuses me. The mingw test tries to run g++ and 
> mingw32-make. Both of them are part of the mingw installation and this should 
> fail if mingw isn't installed. Since the mingw mount point is changed just 
> before this to an non-existing directory, running g++ and mingw32-make should 
> fail, but for some reason it doesn't.
> 
> Hence the script assumes mingw is installed and continues but fails a bit 
> later because it can't find one of mingw's libraries. So it seems that a tag 
> build picks up another mingw somewhere. I haven't figured out where that might 
> come from.
> 
> Anyway, I managed to work around this by manually setting the mingw mountpoint 
> before calling "build_package.sh 2.4.10-1"
> 
> The build is running now. We'll see if it succeeds.

It seems to have failed in MinGW again, this time while trying to extract binutils for mingw. 

Is there any discernible difference between a release build and a nightly besides the filename? Maybe I could just take yesterday's nightly, change the filename, and put *that* up on SF.

Regards,
John Ralls