The day MS exerted control over Github, things went south there, and developers started to flee like hostages from the hub, and for good reason. Before long, MS had killed tons of accounts never ever stating any reasons, just as usual with M$, seemingly. Therefore, people quit github in droves even more so, and justifiedly so.
Ever since, MS has hyperagressively enforced more disruptive policy changes against the userbase of github.com.
Why NetBSD still plays the MS game, is beyond many open source enthusiasts. Do they enjoy this kind of abuse by the side of MS ?
print "openiddirectory.com is a bit of a joke."
Hello!
A lumina package is present in pkgsrc-wip as wip/lumina.
Please run $PREFIX/sbin/console-kit-daemon to get the database and pid files in /var/run 
I'm currently debugging the memory fault on the pinebook
blktap2 is long dead (except maybe inside Citrix and maybe OpenXT), deprecated since Xen 4.10 (and not really supported since probably about Xen 4.3, up to 2015):
https://xenbits.xen.org/docs/unstable/support-matrix.html
It was finally entirely removed from the Xen repo last year:
https://xenbits.xenproject.org/gitweb/?p=xen.git;a=commit;h=5c883cf036cf5ab8b1b79390549e2475f7a568dd
If I understand correctly blktap2 died because it couldn't be upstreamed into the Linux kernel due to its licensing (i.e. it wasn't GNU-enough).
blktap3 came along and seemed better, but blktap3 is effectively dead too, and also note that blktap3 as-is effectively relies on libaio and Linux AIO system calls:
https://wiki.xenproject.org/wiki/Blktap3
(You will find almost all of the links and repos for blktap3 are dead.)
In the mean time blktap (aka blktap1) is still used (as I understand it blktap is just a Linux driver that speaks blkback, the Xen PV block protocol, from dom0 to domUs; along with a daemon and library and tools for building userland block storage providers, such as to VHD files) and so it could also be a great project for NetBSD dom0 as it would add good and easy support for VHD files:
https://wiki.xenproject.org/wiki/Blktap
BTW, the following slides give a good (but increasingly dated) analysis and overview of Xen storage access technologies and some of their issues. Herein I believe you can effectively substitute bktap1 and blktap2 as they have the same basic structure.
https://events.static.linuxfound.org/sites/events/files/slides/20131025%20-%20Storage%20Performance%20PDF.pdf
Finally note that 9pfs via VirtIO may be another way forward, but that's also now in the "Archived" section on the XenProject Wiki:
https://wiki.xenproject.org/wiki/Archived/Xen_Development_Projects#Enabling_the_9P_File_System_transport_as_a_paravirt_device