On Fri, Feb 15, 2013 at 06:44:17PM +0000, Stuart Henderson wrote: > On 2013/02/15 18:28, Jérémie Courrèges-Anglas wrote: > > Stuart Henderson <[email protected]> writes: > > > > [...] > > > > > emacs21,no_x11 fails reliably during link: > > > > Cool... > > > > [...] > > > > > it's pretty sad that only ~320 packages built (and several of these > > > are just "recompress a bunch of files for things which aren't useful on > > > vax anyway"). weird too though, there are various things which should > > > have worked which didn't get built (e.g. math/moo). or even attempted, > > > from the looks of the dpb logs..? > > > > 320, where 5.2 shipped with 2279 packages... > > yeah, something's wrong there eh? I wonder how the next build will do. > (I'm not running them).
One known thing is that vax has crappy limits. 32M of data size, top. Fitting the info for ~7000 ports is what killed dpb previously. There is a lot of code in there specific to vax, so that with -f0, dpb will be really slow (rechecks all distfiles when building) but fit within 32M (there is a whole lot of code in dpb and in the ports tree to try to get stuff to vanish entirely when it's tagged with oNLY_FOR_ARCHS-*/NOT_FOR_ARCHS-*, this shaves about 16M off dpb's memory size). So you have it: around 5.2, a full dpb build did run up to 29M of memory (which corresponds to the info describing the 3000 ports or so that will be attempted...) I've already said that this can only go so far, and it is totally wasteful to run dpb proper on the vax itself. dpb will be perfectly fine on a faster machine: *everything* will be on the vax(en), including scanning the ports tree and building things, so it's NOT cross-build. This would free the vax'n to do ways more useful stuff, and I'm pretty sure it will go faster (well, less slowly is a better way to put it), as the vax is likely to swap and thrash between dpb and what it's currently building... dpb barely shows up as a small blip on top when it's run on a faster machine. You can see it on fast machines with lots of cores, because there's so much activity going on, but say, run dpb on amd64, connect two vaxen to it, you will see a bit of dpb activity every hour or so, and nothing the rest of the time. Yeah, you have to pay for two ssh connections instead of building things locally (switching to rsh if you're on a completely local trusted network would be a piece of cake, btw, todo list for that very slow crap we still run onto). (the only part of dpb that currently relies on a local ports tree is fetching distiles and reading distinfo files, and this is on my list of things to do... This obviously doesn't affect a dpb that runs with -f0).
