Buildfarm try
Simon Ruderich
simon at ruderich.com
Wed Oct 17 13:53:17 PDT 2007
On Sun, Oct 14, 2007 at 10:32:20PM -0500, Ryan Schmidt wrote:
> On Oct 14, 2007, at 17:00, Simon Ruderich wrote:
>
> Very interesting and useful! 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 took my MacBook about 2-3 days which is quite long. I guess the whole port
tree would need at least a week, maybe (much) more.
> It would help to know the date/time when you encountered each failure,
> and/or the revision of the portfile that was used.
Yes, this would be indeed very nice.
> You may want to add a table of contents at the top so we can jump to
> specific ports.
Good idea, I will add this in the future.
> 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 thought it's already sorted alphabetical. Maybe the problem is that ports
with a uppercase name are sorted in an own group at the top, then all
lowercased ports.
> In build.html you have gnome-session, gedit, gnu-crypto, and gnustep-base
> listed several times. Probably others as well.
Yes, this is a problem with the parser I wrote to get the ports. I hope I can
improve it.
> I fixed iksemel's fetch failure. Note that you had iksemel listed
> build.html. You have other fetch failures listed in build.html
> (DarwinPortsStartup, cook, p5-email-address, etc.).
Thanks, I removed it from build.html.
This is also a parser problem, sorry.
> Lots of ports complaining about /opt-devel/bin/python2.4 being missing.
> Aren't those ports in the python portgroup? Wonder what's going on there.
Not sure either. I will look into it.
> 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.
As this was my first test I just executed "sudo port install all" and wrote a
small script which parsed the output of this command. I know see how limited
this approach was, but I'm already working on a better one.
A big problem for example is that some fetches are not failing after a timeout
even if the server is not responding. I'm not sure how to fix this as an own
timeout in my buildfarm would stop long downloads.
My current idea is to get a list of all ports ("port list") and then build
each port after another. Before each new build all other ports are removed
("port uninstall installed"). The output of port is parsed and then based on
this saved in a database which is then used to create the html files.
It would also be good if maintainers could mark a port fixed so it's removed
from the failure list.
But the best thing would be if the buildfarm is linked to the svn tree and
just tries to rebuild new or failed ports so we always know which ones are
failing. I already have some ideas for this and will try to integrate it in my
new approach I'm currently working on.
The only problem is that some ports (like gtk2) need a long time to build so
maybe they shouldn't be removed after each port build.
What do you think of my ideas?
Thanks for your help,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071017/914c993d/attachment.bin
More information about the macports-dev
mailing list