Buildfarm try
Juan Manuel Palacios
jmpp at macports.org
Mon Oct 15 10:26:30 PDT 2007
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
More information about the macports-dev
mailing list