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