make sure your cache/swap drive is big enough. some kernels do not support being "shorted" on that leg.
one symptom of low memory and having a wrongly sized swap drive is: build gets terribly slow, spins constantly slower, appears to freeze PC
yet ... after fixing my cache it would take *days* for "qt-everywhere" (which, btw, is not really Qt), but it would build and finish and wouldn't slow the machine to a freeze
advice: if something warns you to not to make something too small, be sure they aren't saying that for no reason
OOOPS dbus? that's small to compile. and google/debian/ubutu stuff? they will throw a stick in your wheel don't think they wont. fix it and move on.
it >> foo >> foo >> foo certainly appears to be in a erronous loop, possibly in make script or some other script foo.
dbus uses XML, xml is partly based on downloads of templates - some of which may have been hacked. infamously, xml-doc pulls code off a site without any legitimacy, unsure version, and executes code that is downloaded (not binary - but arbitrary commands still; it phones home)
(so to you this means, the template or parsing of is wrong, so the build goes wrong, and your jammed. you should check that what dbus depends on, esp XML stuff, is all straight. you need the exact versions that worked when tested, you dont want some hacked version). unfortunately many these days are offering "only the latest edition" downloads to force people to upgrade and into problems.
likely the inf loop is cause by whatever was built and installed previously - it depends on it being of some particular version, and it isn't
understandably i cannot pin-point that cause without more access to the situation than you should give me
ONE MORE warning - double check the logs make sure the make isn't executing a command that isn't present. that can easily happen. you'd have a failed build but not see a clear reason why (ie, perhaps ports assumes bsd has the command, but the command cannot be found on your system when make runs)
