Render Farm Build 10

DISCLAIMER: This is a continuing series detailing the painful story of a DIY render farm build.  It is terribly technics and
somewhat frustrating.  Those who are unprepared for such “entertainment” are advised to ignore these posts.

Well, the build FAILED.


I forgot to take out ALL the already compiled stolen dylibs out of the /opt directory, and the build has stumbled over a few more of them.  There was a GDK and libpangcairo and some other crap lying around – ugh.  I really should’ve burned the disk down before installing 10.5 so I could have a clean slate…

But then, after cleaning all that stuff out… Success!  GTK2 built successfully.

So… Dr. Queue should work just fine… I ran scons to build the software, and it reported it was done.  There in my Dr. Queue folder were binaries and everything.   So… this meant success?

All I had to do was to configure it.  I checked the .conf files for drqman.  These are the files to tell drqman to use certain folders for logs and temporary files.  These folders must be accessible on the network so that not only the master program (the one I’m trying to compile) but the slave program (on the worker machines) can access the files that need to be rendered and can write the rendered material to a specified location.

With that done, I dragged the command line executable for “drqman” into the terminal.


It bombed out, saying “cannot be wrapped.” Somehow this figures in with X11 but I do not know how.

So, I installed wget so I can retrieve the original sources. Apparently wget is not installed automatically (curl is).  I had been relying on a tarball of Dr Queue from their site, and since this bombed out, shouldn’t I try the original source and not that tarball distribution?  Perhaps I needed a freshest of the fresh clean copy?  I dunno, I was getting desperate.


The wget failed to get the source.  But there are other ways to skin this cat.  If I installed either SVN or GIT I could use either of them to get the sources. I had the wget address for the continuous build version of Dr. Queue – but I was not so sure that’s what I’d want…?

A little explanation here.  When I tried to run drqman it bombed out.  I had no idea why, but I suspected the source I was compiling was bad.  I know now that it was not, and I even have some idea that I probably had everything right at this point.  But I did not know it at the time.

I thought I should rebuild from another copy of the source, as if that would be cleaner or newer or something.  But now the question was this – did I want the latest “release” version of Dr. Queue?  Or the “continuous build?”

“Continuous build” is different from “release” software in that whenever a developer is through with his or her particular piece of code and checks it back in, a computer automatically compiles it and makes it available.  That means all the latest changes are made, but they may be buggy.  The “release candidate” of software is usually more stable and has been thoroughly tested.  But although Dr. Queue is industry quality, it is also slow to update, and the last changes seem to have been made back in 2011.  I thought I’d be OK with either one.

I sent out the wget command for the continuous build Dr. Queue source and a file came in immediately.  It was a 4K placeholder; there was nothing in it. It was a blank file. That was annoying.


Apparently I could still get the source, but only if I used SVN or GIT.  These are two source control packages with which software authors can keep track of unwieldy projects.  I could install the SVN or GIT commands to my system in order to retrieve the source.  Yes, you read that right – I would have to download and compile one of two completely different software tools just to be able to get the source to compile the thing I wanted.

I chose GIT, which is the newer system.  GIT is a distributed software control package.  Developers use it to keep track of everything when numerous coders are working on the same piece – thus it is a standard for open source stuff.  Dr. Queue seems to have one main developer, but since GIT and SVN are the coin of the realm, it seems as though every developer uses one or the other.  At some point the Dr. Queue developers began on SVN and then switched to GIT.

GIT was easy to retrieve, and the libraries were easily built.  I sent the clone command to get the source by GIT.  It was looking good for a moment, and then failed miserably.


So, I downloaded a tarball of the latest build of Dr. Queue again – Grrrr.  This is apparently the only version I could get!  At least for now, and at least with this operating system.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.