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

[Geert Janssens]

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.

Geert