Sorry for the churn, but I think @kib is right and this should be declared in libc_private.h and not namespaced.

Sorry, I should have added you to D49951 and D49952 which this duplicates. I don't think a new library is warranted and if it is, it should probably be libmntopts or the like not something as generic as libmount.

review feedback

I think this is fine for now. Ouch. ;-)

In D49822#1139251, @emaste wrote:

I took a look at my WIP tree and seems like I tried this out:

# Install packages onto release media.
        ${PKG_INSTALL} wifi-firmware-kmod-release || true
# Install pkg for installing pkgbase
#       ${PKG_INSTALL} pkg || true
        ${PKG_CLEAN} || true

Maybe it's sufficient

Seems reasonable to me.
Might be useful in the tests to have the blocks runtime added more centrally, but that looks kinda tricky, so what's here is fine.
I can't review the block stuff in detail since I've not used it, but it seems right or very close to right.

In D49913#1139253, @kib wrote:

If both flags are present, it is more a user error than a useful configuration.

In D49733#1139128, @aokblast wrote:

I think it is for consistency as all standard C library call point to the actual implementation in namespace.h?

More strings editing.

In D49913#1139212, @olce wrote:

I did not follow too closely (was off), but wouldn't it be more prudent to have la48 have priority over la57 when both flags are present? Two of the inline comments I added are changes needed if you choose so.

In D49822#1139248, @manu wrote:

For graphical installer and wifi/drm firmwares we will need full pkg and the pkgs on media, maybe @bz started something on this ?

In D49822#1139248, @manu wrote:

For graphical installer and wifi/drm firmwares we will need full pkg and the pkgs on media, maybe @bz started something on this ?

In D49822#1139239, @emaste wrote:

1. Include a fully bootstrapped pkg in the install media. We will want this anyway eventually for fully offline install media. There are potential forwards compatibility concerns however if we do not also include all packages to be installed in the install media.
2. Add a feature to pkg(7) which fetches and extracts pkg-static to an arbitrary location without installing it. Use this feature to fetch pkg-static to /tmp and run it from there.
3. Bootstrap pkg directly in the chroot, adding features to pkg(7) as needed.

We are going to need pkg available to install pkgbase from release media, indeed. I'm not sure that implies #1 is necessary though -- 2 and 3 would work just as well installing from an on-disc repo I believe.

That said, at least some install media variants are going to need a set of installed packages for the installer to work (e.g. for graphical installers), so perhaps it's not any effort unique to this.

1. Include a fully bootstrapped pkg in the install media. We will want this anyway eventually for fully offline install media. There are potential forwards compatibility concerns however if we do not also include all packages to be installed in the install media.
2. Add a feature to pkg(7) which fetches and extracts pkg-static to an arbitrary location without installing it. Use this feature to fetch pkg-static to /tmp and run it from there.
3. Bootstrap pkg directly in the chroot, adding features to pkg(7) as needed.

In D49492#1130953, @bnovkov wrote:

There's one additional thing I'd like to point out here - the msdos backend does not pass these tests ATM, it's atime is completely different while mtime and ctime get set to timestamp - 1. I'll look into this separately.

I'm fine with reverting the change until the bug can be found.

• Add pmap_kmapped_range to check if a range is mapped & use it in pmap_mapbios
• Reset memory attribute and protections on unmap

I did not follow too closely (was off), but wouldn't it be more prudent to have la48 have priority over la57 when both flags are present? Two of the inline comments I added are changes needed if you choose so.

You can drop the license boilerplate and just have the SPDX tag, if you like.

In D49492#1139179, @bnovkov wrote:

In D49492#1131965, @jlduran wrote:

These are all good (at catching the current failures).
My only concern however, is that we should also check that makefs takes into consideration the timestamp in the mtree file, so the priorities (at this point of the revision stack) are:

1. -T flag .
2. Time in mtree file.

This guarantees (or not) documentation on the behavior regarding the priorities when the SOURCE_DATE_EPOCH environment variable is introduced later on (D49602).

Thank you for pointing this out and for sketching out the testcase!
After a brief discussion in D49531, the consensus was that the timestamp sources should be prioritized as follows:

1. -F mtree specfile time
2. -T
3. Timestamp in input mtree file

I've added testcases that test the interactions between -F and -T.

New wording LGTM

New wording LGTM

Note that O_CLOEXEC is set in "fmode" near the top of main()
for the second open.

Marked inline comments as done.

Missed a couple of cases for .Ar file. Fixed now.

Updated man page with changes suggested by ziaa@.

Updated the man page to reflect the use of /bin/sh.

Tweak wording to match changes in D49823

Thanks for the review @jhb!

In D49492#1131965, @jlduran wrote:

These are all good (at catching the current failures).
My only concern however, is that we should also check that makefs takes into consideration the timestamp in the mtree file, so the priorities (at this point of the revision stack) are:

1. -T flag .
2. Time in mtree file.

This guarantees (or not) documentation on the behavior regarding the priorities when the SOURCE_DATE_EPOCH environment variable is introduced later on (D49602).

Tweak wording based on jhb review, simplify logic

Address @jlduran 's comments - add testcases that test the interaction between -F and -T

In D49822#1138083, @emaste wrote:

I built a disc1.iso with these changes and the installation failed after the root password prompt.

handle return code of OF_getencprop() correctly

Modify all nvidia-drm ports

I think it is for consistency as all standard C library call point to the actual implementation in namespace.h?