On Jan 5, 2008, at 19:18, Ryan Schmidt wrote:
On Dec 29, 2007, at 09:12, Chris Janton wrote:
On 2007-12-29 , at 05:16 , Boey Maun Suang wrote:
Unfortunately, we don't seem to have too many people with Panther
boxes
who are able to help us test on that platform. If you, or indeed
anybody
else, would like to help me and see if they can reproduce the
runtime
error I describe, we'll be happy to post how to do so.
I would be glad to help figure things out for Panther. I don't
expect to be upgrading that OS for some time (long) so having a
working, viable MacPorts is important to me.
Probably what we should do first is determine the specific commit /
revision / changeset that broke the build on Panther. I don't think
we've established that yet. My wild guess was revision 29498. To
test whether that's the culprit, check out trunk at r29497 and
build it on Panther. If it builds, then check out trunk at r29498
and build it. If it fails, then r29498 broke the build, and we can
further analyze the changes made in that revision.
If r29497 already doesn't build, then go further back through the
revisions. Try a binary search pattern of revisions between r29497
and r27897 (which is when the 1.5.2 tag was created) to try to find
the one revision that breaks the build. Or, if r29498 still builds,
then continue forward through the revisions. Binary search between
r29498 and r32094 (which is when the 1.6.0 tag was created).
Oh, um... I guess it wasn't that the build fails, it was that the
port command doesn't work for some subcommands and complains about
ui_channels. So after you build a given revision of trunk, test those
failing port commands to see if they fail.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
