Hi Steve, > Last time we updated the rabbitmq-server macports package, it transpired that > an upstream change had been made (changeset r87628). > > Can you please explain what it is that made you think this change was > necessary? We can't see why we would ever use the HOME environment > variable in the build. the HOME enviroment variable is only set to please the macports buildbot. Maybe this should have been made clear in the commit message.
On the buildbot machine the home directory cannot be accessed which causes a lot of file:path_eval([".","/var/root"],".erlang"): permission denied errors because the erlang runtime tries to find a ".erlang" in the home directory at startup. See the build log for the rabbitmq-server before r87628: http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/3342/steps/compile/logs/stdio I don't why this breaks the build. AFAIK the erlang runtime runs just fine without a ".erlang" file, but back then I didn't had the time for further investigation. You can easily reproduce this behaviour. Just create an unreadable ".erlang" file in your home directory: touch ~/.erlang && chmod u-r ~/.erlang Then try to build rabbitmq-server. > In this context, this team finds its macports expertise stretched to the > limit (nearly every release) and would really like to find someone from the > community to support the packaging of rabbitmq-server for macports. > > Any idea where we might ask for this sort of ongoing assistance? > If you like, I would step in as a co-maintainer. I'm not that familar with rabbitmq but I have some experience with erlang (maintaining the ejabberd and Yaws port) and macports as well :-) Regards, Christoph
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
