Intltool has moved to launchpad
Submitted by jralls on Fri, 2009-04-17 01:49.
So gtk-osx-bootstrap.modules needs to be modified. I've been trying to figure out the correct syntax for a bazaar repository, but the example in the jhbuild docs isn't working for me: I keep getting "error during stage checkout of intltool: bzr not found".
Here's what I started with:
<repository type="bzr" name="launchpad.net"
href="http://bazaar.launchpad.net"/>
<autotools id="intltool">
<branch module="intltool" repo="launchpad.net"/>
<dependencies>
<dep package="gnome-common"/>
<dep package="perl-xml-parser"/>
</dependencies>
</autotools>
I tried variations on the href and on the module id to no avail.

Well duh, now I see that
Well duh, now I see that it's complaining that bzr isn't installed on the computer. I'll take another whack at it tomorrow.
I think it's better to make
I think it's better to make the moduleset use a release tarball so we don't add a dependency on bzr.
OK, no argument with that.
OK, no argument with that. Why didn't you?
In fact, I've been pondering creating a release-only moduleset, using VCS release branches where available and tarballs where not, to provide a more stable build environment for GnuCash. Aside from ige-mac-integration, are there any packages where there's a big advantage to dealing with the constant churning characteristic of the trunk branch?
It's good idea, I have been
It's good idea, I have been thinking about doing just that for a couple of years but never got around to do it :)
I started out with using bleeding edge of everything as so much didn't work that well and often needed fixes. But now the situation is much better.
I don't think any module really needs to taken from trunk, release tarballs or tags should be totally OK for most people (since most people aren't developing gtk+, just using it).
I updated the moduleset to
I updated the moduleset to use a tarball for intltool.
Thanks, I got another
Thanks, I got another complaint about it over the weekend.