The fstype is fuse.scribus-1.5.6.1-linux-x86_64.AppImage; options are fd=5,rootmode=40000,user_id=0,group_id=0.

The code looks good to me. Was the problem that a Linux command like "mount -t fuse.ntfs ..." wouldn't work?

In D30559#686263, @imp wrote:

I love this, though in time we may need to change the usernames a little depending on where we land.

For now, this is great, since we don't have pull requests turned on in gitlab that I can see.

Works for me. You should also reenable the test in tests/sys/fs/fusefs/write.cc.

This has now passed a make tinderbox.

There are also some header files in cddl/compat/opensolaris/include/ . Some of those are definitely needed, but I'm not sure about all of them.

Yep. That's wrong. In 14.0-CURRENT, the function that sets physpath is ses_set_physpath, in cam/scsi/scsi_enc_ses.c.

In D29941#676901, @mav wrote:

Excuse me if I am wrong, I don't have any multipath environment now to make sure, but I remember that SES on different expanders of dual-port backplane report different IDs.

In D29941#676861, @mav wrote:

I'm sorry for missing it earlier, but if there are actually several paths through the different HBAs and enclosures, what of the paths do you report? Random currently active one? Wouldn't it be better to not pass it through at all, unless we can somehow map all paths into something shared?

In D29901#671164, @0mp wrote:

I've got some minor fixes for the manual page.

Also, just an idea: shouldn't we extend libxo with Prometheus support? This way we would have a consistent way of printing this format across various utilities without having to introduce a different flag for each one.

• Respond to 0mp's man page review

Well, I don't see anything wrong with the code, @rmacklem . But I'm so ignorant of the protocol that I'm afraid I'm not able to give it a very good review.

Sorry I'm late to the party, but I have a few questions:

It doesn't matter, because Kyua executes the tests in separate temporary directories.

It shouldn't matter that they're using the same file name, because Kyua runs each test case in a separate temporary directory. Also, when you use Phabricator please include full context . The best way to do that is to create your revisions using arcanist (available in ports as devel/arcanist-php*. Or if you're uploading diffs through the web interface, generate them using the -u 9999 option.

• Remove redundant variable assignment

Superseded by https://svnweb.freebsd.org/changeset/ports/567499 by @kai

In D29065#651018, @arichardson wrote:

In D29065#650983, @asomers wrote:

Your assertion that these are all POSIX sh scripts with ksh93 helpers is not correct. For example, hotspare/hotspare_test.sh sources hotspare/hotspare.kshlib, and that file makes use of ksh arrays. You therefore can't invoke hotspare_test.ksh with sh.

Do you happen to know how many of the ATF scripts need to be executed as ksh93? Would it be feasible to change them to run the actual tests in a new ksh93 shell? Or maybe re-exec if $0 == sh?

In D29065#650987, @arichardson wrote:

I guess the real fix would be for kyua to not bother running $test -l if required_programs is missing...

I didn't look at every file, but the overall pattern looks good. However, the fact that require.progs in a test file overrides the setting in the Kyua file, rather than adding to it, is arguably a bug. Maybe you should open a bug report upstream.

Your assertion that these are all POSIX sh scripts with ksh93 helpers is not correct. For example, hotspare/hotspare_test.sh sources hotspare/hotspare.kshlib, and that file makes use of ksh arrays. You therefore can't invoke hotspare_test.ksh with sh.

I think the current version is better than always using the fallback. Just fix the lint issue and I'll accept it.

There's no way that EINVAL and ENOSYS are more common than errors like ENOSPC, EROFS, and EACCES. The latter three can happen in regular production environments, but the first two can only happen when building new releases like you found, or after an upgrade gone wrong.

We probably don't want to try the fallback path for cases like ENOSPC and EACCES. I think the original code, explicitly checking for ENOSYS and EINVAL, is better. BTW, I successfully built 13.0-BETA3 on 12.2-RELEASE yesterday. However, I did not use release.sh just buildworld and buildkernel. Is that your experience too, that release.sh is necessary to trigger the bug?

Um, what do you mean by that, @cem ?

• style(9)