Address sugesstions:

• Rebase
• Bump date

Yes, this is much better. A "permanent" fix.
It has bitten us before (D49739#1134004).
Thank you!

Upstream has already applied the patch.

The equivalent fix has been reported upstream as: bin/60270 (GNATS)

Looks good.
I get an extra diff after freebsd-configure.sh and freebsd-namespace.sh:

diff --git a/crypto/openssh/krb5_config.h b/crypto/openssh/krb5_config.h
index d95deef0b087..21fde75751e9 100644
--- a/crypto/openssh/krb5_config.h
+++ b/crypto/openssh/krb5_config.h
@@ -1,5 +1,14 @@
+#define ENABLE_SK_INTERNAL /**/
 #define GSSAPI 1
 #define HAVE_DECL_GSS_C_NT_HOSTBASED_SERVICE 1
+#define HAVE_FIDO_ASSERT_SET_CLIENTDATA 1
+#define HAVE_FIDO_CRED_PROT 1
+#define HAVE_FIDO_CRED_SET_CLIENTDATA 1
+#define HAVE_FIDO_CRED_SET_PROT 1
+#define HAVE_FIDO_DEV_GET_TOUCH_BEGIN 1
+#define HAVE_FIDO_DEV_GET_TOUCH_STATUS 1
+#define HAVE_FIDO_DEV_IS_WINHELLO 1
+#define HAVE_FIDO_DEV_SUPPORTS_CRED_PROT 1
 #define HAVE_GSSAPI_GSSAPI_GENERIC_H 1
 #define HAVE_GSSAPI_GSSAPI_H 1
 #define HAVE_GSSAPI_GSSAPI_KRB5_H 1
diff --git a/crypto/openssh/ssh_namespace.h b/crypto/openssh/ssh_namespace.h
index 71b53d286dbf..c18171ba7807 100644
--- a/crypto/openssh/ssh_namespace.h
+++ b/crypto/openssh/ssh_namespace.h
@@ -399,6 +399,7 @@
 #define libcrux_ml_kem_ntt_ntt_at_layer_4_plus_ea Fssh_libcrux_ml_kem_ntt_ntt_at_layer_4_plus_ea
 #define libcrux_ml_kem_polynomial_ntt_multiply_d6_ea Fssh_libcrux_ml_kem_polynomial_ntt_multiply_d6_ea
 #define libcrux_ml_kem_polynomial_poly_barrett_reduce_d6_ea Fssh_libcrux_ml_kem_polynomial_poly_barrett_reduce_d6_ea
+#define libcrux_ml_kem_sampling_sample_from_binomial_distribution_a0 Fssh_libcrux_ml_kem_sampling_sample_from_binomial_distribution_a0
 #define libcrux_ml_kem_serialize_deserialize_ring_elements_reduced_1b Fssh_libcrux_ml_kem_serialize_deserialize_ring_elements_reduced_1b
 #define libcrux_sha3_generic_keccak_keccakf1600_80_04 Fssh_libcrux_sha3_generic_keccak_keccakf1600_80_04
 #define load_hostkeys                          Fssh_load_hostkeys

I'm only testing on aarch64 (extra ssh_namespace entries may appear).

Yes, thank you for the feedback and thank you for working on this.
I think from the user's perspective, this is much better!

I can understand we want to keep it as close as to what it currently is. And now I agree that this should be the way to go.
In the pull request you asked me if I had a different take on it: so, originally my approach was, given that they're all packages, regardless of their repo, a user could define something like:

PARTITIONS=DEFAULT
PACKAGES="FreeBSD-set-base FreeBSD-kernel-generic puppet" # Or PKG_LIST
#METHOD="packages" # This is the default

Not sure about the snapshot wording, but that's similar to what we've don in the past.
Thank you for creating this revision!

I had more time to test this change. I might change it to:

chmod "$mode" "$dir"
[ -L "$dir" ] && chmod -h "$mode" "$dir"

because it produces the "right" mtree, so that when it is a symbolic link, it takes the mode of the symbolic link itself and not the target (that is why I'm inclined to also add chmod -h so both, the target directory and the symlink have the desired mode).

In D56717#1299780, @asomers wrote:

In D56717#1299770, @ziaee wrote:

We're trying to avoid making pkgbase a proper user facing noun

What do you suggest instead? Is there a different phrase to use, or should I make pkgbase mandatory in bsdinstall and remove mention from the man page?

I recently learned that the official term is freebsd-base(7).

cc/ @senguptaangshuman17_gmail.com

Thank you for the input.
I will note that in the documentation patch for bsdinstall(8). This patch will be abandoned, the other two in the stack will remain, because they are essentially a cleanup with no functional changes.

Address suggestions:

Yes, I agree. My original plan was to only select the MANDATORY options by default.
But giving it a second thought, maybe I should change it to explicitly set default_lib32 to on (it is currently set to on because there is no default_lib32), and clearly state in the commit that this is to have 32-bit support for some popular ports by default (wine, steam, etc.)?

Hi @senguptaangshuman17_gmail.com, this revision is still missing a few tests. I plan to add them after this week's meeting.

Hi @0mp would you mind if I take a stab at extending this patch a bit further or maybe you would like to extend it?
For some context, I am currently working on adding a precompiled option to NanoBSD as part of a GSoC project. It requires using pkgbase, however I found it very useful to also add distribution sets for comparison. As such, we have decided to adopt bsdinstall's configuration options, that is, defining a NANO_DISTRIBUTIONS variable with the distributions you want in the final image. I'm pointing users to this manual page for more information about DISTRIBUTIONS.
My extension will consist of presenting more verbose distribution set information (obtained from the MANIFEST), which includes all the valid options the user can choose:

base-dbg.txz		"Base system debug info"			off
base.txz		"Base system"					on
kernel-dbg.txz		"Kernel debug info"				on
kernel.txz		"Kernel"					on
lib32-dbg.txz		"32-bit compatibility libraries (Debugging)"	off
lib32.txz		"32-bit compatibility libraries"		on
ports.txz		"Ports tree"					off
src.txz			"System source tree"				off
tests.txz		"Test suite"					off

The third column is what bsdinstall selects by default when running interactively (for reasons beyond my understanding, I would have selected base.txz kernel.txz by default as well).

Thank you for working on this!

Yes, this should be pretty straightforward.
I added the network project, just in case. Let's wait one more week, plus an MFC of one week after that.
If this is time-sensitive, let me know and I will commit sooner. Thank you!

OK, if this is indeed what you prefer, I would only ask that in the commit message at least some of the discussion in the PR is stated. Something along these lines:
The NETWORKING script was created to avoid conflicts between the NETWORK script and the network script (present on NetBSD) when the file system is case-insensitive. NETWORK was maintained as an alias for compatibility with old scripts... (please feel free to paraphrase).

Thank you!

Nice! I'm sorry, but I found one very minor thing. REPODIR is unset in bsd.pkg.mk, therefore creating the repo directory under /, I documented inline what I did in order to make it work.
Besides this minor issue and the missing machine-specific Makefiles you mentioned, everything else is superb!

Please see: D56118.

In D56117#1283524, @ivy wrote:

that sounds reasonable. note this blocks D56087, so i'm interested in the result.

Give me some time to test it, but I think it is better if we just update share/mk/src.opts.mk (and regenerate the manual page afterwards):

.if ${MK_BLOCKLIST} == "no"
MK_BLACKLIST:=	no
.endif

In D56070#1283471, @ivy wrote:

fwiw, i think this is fine to land before D56087 as long as you're only doing something like .export SOURCE_DATE_EPOCH in Makefile.inc1. that should be picked up automatically by the <bsd.pkg.mk> build.

edit: this is partly why i suggested using .export instead of editing the pkg commands.

Thank you! It works well now (overall). There are a couple of things that fail on aarch64 (described inline). Other than that, this is great. Thank you!

In D56087#1282872, @ivy wrote:

In D56087#1282809, @jlduran wrote:

I have briefly tested this patch, and I'm getting:

/usr/libexec/flua: /usr/src/release/packages/generate-ucl.lua:77: attempt to call a nil value (method 'match')

As if the previous clean step did something it should not do (it dirtied the repo). Please disregard if I'm doing something evidently wrong.

i will try to reproduce this here, but in the mean time, could you please share a full make buildworld / buildkernel / update-packages log?

In D56087#1282872, @ivy wrote:

In D56087#1282809, @jlduran wrote:

I have briefly tested this patch, and I'm getting:

/usr/libexec/flua: /usr/src/release/packages/generate-ucl.lua:77: attempt to call a nil value (method 'match')

As if the previous clean step did something it should not do (it dirtied the repo). Please disregard if I'm doing something evidently wrong.

i will try to reproduce this here, but in the mean time, could you please share a full make buildworld / buildkernel / update-packages log?

In D56087#1282790, @ivy wrote:

@jlduran, @imp: this may impact what you're working on for nanobsd.

In D56070#1282531, @ivy wrote:

i have a strong preference for using SOURCE_DATE_EPOCH here, if possible: it will avoid conflicting with some other pkgbase work i'm doing, and more generally seems like a cleaner solution as anything that needs that can easily consume it; this is information that should be generally available to the build system.

In D56070#1282516, @kevans wrote:

Specify the modification time (mtime) of the files to match SOURCE_DATE_EPOCH rather than the current time when creating packages.

Can you spell out a little more clearly in the commit message why pkg's automatic SOURCE_DATE_EPOCH usage isn't sufficient here, please? By all accounts it seems like this should be a nop, so I guess it's that SOURCE_DATE_EPOCH isn't exported into pkg's environment in these targets?

In D56013#1281115, @ivy wrote:

./boot type=dir uname=root gname=wheel mode=0755 tags=package=bootloader,utilities

i don't think this is right (and based on what i remember of mtree-to-plist, i'm not sure it'll even work). /boot should be owned by the bootloader package; if something is adding a package=utilities tag to it, whatever's doing that should be fixed.

• Previous revision stack was committed.
• All possible improvements that derive from this file, will be re-submitted.