pkgsrc-2011Q2 has been released. This is the first release which is really usable on MirOS. Bootstrapping works without applying patches before; I updated the pkgsrc instructions accordingly. During the freeze, there were two last-minute fixes to important base packages (gmake and glib2) which did not go in before the branch was cut off. One of them (gmake) has been pulled up on my request after Alistair G. Crooks encouraged to do so.

I finally managed to get a MirOS instance running on Xen with HVM using NetBSD-current as the Domain-0. I had to compile my own DOM0 kernel to include support for the alc ethernet driver—yes, the one where I did not manage to fix the driver under MirOS. The first impression: Compilation and other CPU-intensive tasks are very fast, while I/O is quite slow. The qemu-dm process, which provides hard disk and network drivers to the DomU, seems to get congested quite rapidly. Btw, emulating an Intel Gigabit network card works very well with our em(4) driver.

To profit from the VM, I set up a bulk build with a fresh pkgsrc-2011Q2 checkout, using the pbulk framework. Technically, it looks very nice and more sane overall than a simple recursive make: there is a scan phase at the start, where a dependency tree of all packages is constructed. Then, a master process decides which package to build next. It can optionally distribute the builds over several machines at once. However, I found the documentation to be severely lacking; what’s more, the pkgsrc guide and the doc/HOWTO-pbulk file have obviously been written by persons with different approaches w.r.t. suggested directory layout etc.

I created a NetBSD slice of 55 GiB, mounted in MirOS under /pbulk, for all data relative to the bulk build and added it as a physical device in the VM configuration. However, the I/O congestion becomes worse after some time building things. The ssh connection becomes more or less unresponsive, and qemu-dm takes 100% of the Dom0 cpu. Even after stopping the build with ^Z, the hard disk is thrashing for several minutes with qemu-dm at 100% cpu, before slowly going back to normal after a few minutes. WTF? For what it is worth, the VM has 1 GiB of RAM allocated and no swap. More tuning required …