On Oct 14, 2007, at 11:32 PM, Ryan Schmidt wrote:
On Oct 14, 2007, at 17:00, Simon Ruderich wrote:
I tried creating a small "buildfarm" using my MacBook Pro. I
already have some
results, but it's just a small test, so please be not too strict
with it ;-)
You can find the results here: http://ruderich.com/simon/macports/
But the results are some days old, so it may be possible a port is
already
fixed. I'm sorry but at the moment I don't have any dates.
It would be nice if some of you could use these results to fix
broken ports.
I separated fetch failures from build/other failures so they
should be easy to
fix.
If you have any suggestions/improvements/bugs or questions please
tell me.
Very interesting and useful!
Very useful indeed! Tabulation of build-run results is another one
of the "services" MacPorts is sorely lacking. And I say "services"
because I see this functionality more as a server side thing that can
be fed day in and day out by logs created by, you guessed it, http://
trac.macports.org/projects/macports/wiki/PortLoggingProposal ;-)
Some random comments:
I hope you will regenerate this occasionally, at least those that
are failing right now. How long did it take to generate that list?
It would help to know the date/time when you encountered each
failure, and/or the revision of the portfile that was used.
You may want to add a table of contents at the top so we can jump
to specific ports.
You may want to sort the ports in some way. It currently seems to
be somewhat alphabetical, but with other ports in between (maybe
dependencies?).
I would totally love it if any scripting that's put together to
preprocess build result logs is done openly (that is, in our svn ;-)
and in coordination with the login proposal above and the new
website. Admittedly there's still a lot to discuss to even figure out
some basic guidelines for the development of such script(s), so
basically lets consider this message of mine a call to start tying
some of those loose ends. For starters, I propose that, at least for
starters:
*) the script(s) is (are) written in php and checked into some subdir
of trunk/www (trunk/www/buildresults/ ?), so that the resulting web
pages tie nicely into our new project homepage.
What I envision moving forward is a full blown section of our
project website dedicated to the tabulation of build-run result logs
once we get our infrastructure (both hardware and software wise) in
shape to host the build-runs themselves. Links to this new section
could be created anywhere, like on the sidebar (to an introductory
web page for our build-run results) and off the "Available Ports"
page (which could sport direct links to individual ports build result
tables), among others.
Some of your failures are suspicious. For example:
php5 does not fail under normal circumstances, so I'd like to know
how your build farm is operating.
You report a gettext/libintl build failure for grep that I am
unable to reproduce. The portfile includes the --disable-nls flag
so I cannot imagine why it would be trying to link against gettext/
libintl.
The reported build failure for ufraw ("Image error: /opt-devel/bin/
dcraw is being used by the active dcraw port") is curious since
ufraw does not depend on dcraw (not even indirectly). Why was dcraw
installed? I would think a build farm would need to build each port
in a clean system.
Much of the protocol for build-run results to be reliable still has
to be defined (things like build frequency and creation of a "clean"
environment, among many others), but getting this show on the road by
taking some stabs at how results page might look like (the proposed
scripts above) is by no means out of the question, in my opinion.
So... Simon and Ryan, did I manage to nourish your interest into
putting some lines of php code together? ;-)
Regards,...
-jmpp
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
