They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
The (weird) background is: Support for #Linux xattr syscalls was added quite recently, and it correctly maps the Linux syscalls to the FreeBSD ones. So far, so good. BUT: Access to the "system" namespace for extended attributes is typically restricted to root (and, on FreeBSD, also restricted in #jails). Now, FreeBSD returns EPERM on rejected attempts, which IMHO makes perfect sense. But, Linux returns ENOTSUP in these cases instead. And: GNU tools and other Linux software using extended attributes consider EPERM a fatal error as a consequence. This means things like "install" from GNU coreutils are now broken in jails and as non-root. 🤯
Minor news from my #FreeBSD#Linuxulator userland project: I now succeeded to build a first "dependency monster" (in order to have all features consumers might expect): #cairo. Among other things, required porting all the #Xorg libs first 😉
That's #Linux port #151 I added, it has almost everything enabled that's in the default options of the FreeBSD port. I left out a few things that seemed (too) complex like vulkan ... 🙈
I guess now it's time to double-check the branch on other architectures and other FreeBSD versions first. And then, finally, check whether #MakeMKV will work fine with this!
Double-checking still in progress. So far, fixed an issues on 13.2/aarch64, another one on 14-CURRENT/amd64 (yep, didn't upgrade my #FreeBSD test builders to 15-CURRENT yet 🙈) and yet another one on 14-CURRENT/i386.
Now, test builds for 13.2/i386 are running. We will see. Once I'm sure the #Linuxulator version of #ffmpeg builds fine everywhere, I'll finally check #MakeMKV 😎
Did all these tests, did some fixes, "#Linuxulator userland from source" branch builds fine on #FreeBSD 14-CURRENT/13.2-RELEASE, aarch64/amd64/i386 🥳
Now doing test builds with 15-CURRENT, which already has a fix for the #Linux#xattr issue. Unfortunately, it's still incomplete. Neverending story 😞
JFTR, not blaming dchagin at all. It seems Linux has some very weird design decisions, and semantics of the xattr syscall return codes -- EPERM is considered fatal by GNU/Linux tools, because Linux returns ENOATTR or ENOTSUP when access to e.g. the system namespace is restricted 🤯
@zirias sure, EPERM typically means you tried to do something your user cannot do at all. As opposed to EACCES, which means you tried to access something that you could have done, if its permission bits had allowed it.
@hyc Still, #Linux uses neither of them. The "system" namespace of extended attributes is restricted to the superuser (and on #FreeBSD, additionally in jails). This doesn't depend on any permission bits, so I don't even think EACCESS would be a better match here. But what #Linux does is: return ENOATTR on attempts to read these attributes, and ENOTSUP on attempts to write or list them. Does this make sense? IMHO not so much. #FreeBSD returns EPERM in these cases, which GNU/Linux tools interpret as a fatal error condition, breaking e.g. 'cp' and 'install' from GNU coreutils. So, FreeBSD's implementation of the Linux syscalls needs some mapping of return codes as a workaround ....
@zirias ENOATTR doesn't make sense for a permission failure, no. Likewise you'd only expect ENOTSUP if the underlying FS doesn't support xattrs at all. And I wouldn't expect EPERM in that case, certainly.
@hyc Yep. the issue here is really #Linux doing weird things. And userspace tools relying on that. I didn't check it myself, but according to dchagin, in Linux, the filesystems implement the access policies for extended attributes... this is IMHO another weirdness, it shoud really be generic (as it is in #FreeBSD). But at least, the filesystems in Linux seem to be consistend with their error codes, so we can emulate that 😜
Add comment