I don't know if you ever solved your ACL problems, but to compile the kernel with NFSCL, you may also need NFSCLIENT:
options NFSCLIENT
options NFSCL
...or so it seems because I can't get my kernel to compile without both lines. Note that the instructions in nfsv4(4) say to use NFSD...
I see -- benefits are twofold. Still I'm not sure I want to spare 4 drives for parity, especially since my daily access will be bottle-necked by gigabit ethernet.
I'm still a little foggy about what those features add over a RAID card, which can also rebuild when a replacement drive is...
Thanks to phoenix for this info. I too just assembled a hardware RAID (RAID6) and was curious how the filesystem would expand when I add drives in the future. Since I am using an Areca ARC-1680ML, which has an Intel IOP348 XOR engine, I believe it makes sense to keep using the hardware RAID...
I don't know where libintl.so.8 should be, but portmaster -w put it in /usr/local/lib/compat/pkg
From UPDATING:
If there are still ports on your system that are looking for libintl.so.8
(either in ${LOCALBASE}/lib/compat/pkg, or non-existent), _please_ file
a PR so that a correct direct...
Turns out a reinstall of gettext did the trick:
portmaster gettext
I guess that is pretty much what DutchDaemon suggested after all. I thought the original "portmaster -w -r gettext" would have started by upgrading all of gettext. Apparently a number of binaries were held back even though...
I get the same error with devel/glib20 when running portmaster -w -r gettext.
The old libintl.so.8 exists in /usr/local/lib/compat/pkg/libintl.so.8, but glib doesn't care.
I tried symlinking:ln -s /usr/local/lib/libintl.so.9 /usr/local/lib/libintl.so.8
but that had no effect on the glib20...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.