Rework test case

In D41983#957328, @arichardson wrote:

You could push to a GitHub fork, then it will run the bootstrap steps as part of the GitHub action

In D41927#956266, @kib wrote:

In D41927#956264, @yuripv wrote:

In D41927#956261, @kib wrote:

I do not know much about runes/locales either.

I'm not that worried about the fix itself, more about adding the public symbol to libc, and wanted to hear from you if this is acceptable.

If the symbol is needed, why not? The concern is that we must support it forever, with the same or compatible semantic. But then again, this is the question for the locale code maintenance.

In D41983#957267, @yuripv wrote:

In D41983#957266, @arichardson wrote:

This will almost certainly break the cross build. The typedefs in the local _ctype.h are needed. Can you modify that file to include the new generated header?

Yep, I am working on getting cross-build, but I don't see why it would break though, nothing in ctype.c uses those types and we are not including/using the is*() functions.

In D41983#957266, @arichardson wrote:

This will almost certainly break the cross build. The typedefs in the local _ctype.h are needed. Can you modify that file to include the new generated header?

Apparently NetBSD has a bit more complete fix for this (thanks Kyle), use it instead.

In D41927#956261, @kib wrote:

I do not know much about runes/locales either.

• Versions.def updated in separate commit
• drop extern as suggested by Konstantin

complete change (except for linux cross build testing)

As discussed with Mina on IRC, entries with correct email but missing accent in surname need to be normalized as well, i.e.

diff --git a/.mailmap b/.mailmap
index 3760aeece44..1f27f22efdb 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1,5 +1,6 @@
 <ehem+freebsd@m5p.com> <ehem_freebsd_m5p.com>
 <ehem+freebsd@m5p.com> <ehem_freebsd@m5p.com>
+Mina Galić <freebsd@igalic.co> <freebsd@igalic.co>
 Mina Galić <freebsd@igalic.co> <freebsd_igalic.co>
 Mina Galić <freebsd@igalic.co> <me_igalic.co>
 Mina Galić <freebsd@igalic.co> <me@igalic.co>

(re)generate nn_NO.ISO8859-15 from CLDR

In D41899#954906, @imp wrote:

Though nynorsk and bokmal aren't quite the same, this does fix the circular issue. And the two are close enough.

Just wondering what triggered this change, i.e. does it fix any known issues?

In D41329#941150, @jrtc27 wrote:

Try https://termbin.com/d958

In D41329#941144, @jrtc27 wrote:

In D41329#941142, @yuripv wrote:

In D41329#941115, @jrtc27 wrote:

Ok, I think I understand what's going on here. Does https://termbin.com/895q resolve the issue instead for you? That's what we're actually trying to do here, I think.

The following part from your patch is enough to unbreak gcc and is exactly what the patch here does:

--- a/sys/sys/linker_set.h
+++ b/sys/sys/linker_set.h
@@ -66,8 +66,8 @@
 #endif
 
 #define __MAKE_SET_QV(set, sym, qv)			\
-	__WEAK(__CONCAT(__start_set_,set));		\
-	__WEAK(__CONCAT(__stop_set_,set));		\
+	__GLOBL(__CONCAT(__start_set_,set));		\
+	__GLOBL(__CONCAT(__stop_set_,set));		\
 	static void const * qv				\
 	__NOASAN					\
 	__set_##set##_sym_##sym __section("set_" #set)	\

I know, but it's bogus to mix things like this. There's a lot of detail in all this that you're glossing over by just doing that. You need the rest to make it less fragile in corner cases, and of course to make it work for both LLVM's assembler and binutil's.

In D41329#941115, @jrtc27 wrote:

Ok, I think I understand what's going on here. Does https://termbin.com/895q resolve the issue instead for you? That's what we're actually trying to do here, I think.

In D41329#941115, @jrtc27 wrote:

Ok, I think I understand what's going on here. Does https://termbin.com/895q resolve the issue instead for you? That's what we're actually trying to do here, I think.

Committed in rGb306c604df541dede4d0f3cc96188bbf5b6719fe.

Hmm, this doesn't seem to be automatically closed on commit.

add some \n's

In D41056#934733, @mav wrote:

I like removal of IN_FREEBSD_BASE. I would be happy if autotrim was enabled by default, but if it wasn't for some time, then I see no problem to clean this up. I just wonder how long it was broken. Respective part of the patch will need to be upstreamed to OpenZFS also, may be in parallel to make sure more people are in sync about it.

Sadly, I had to revert this, with all these defines being ambiguously named I missed the fact that IN_BASE is only used in FreeBSD-specific code to signify userland/kernel differences, while IN_FREEBSD_BASE really means FreeBSD-specific code inside the common code. Will need to think more about proper approach (and naming?) here.

modify spa.h instead as proposed by Warner

re: stand, I don't see a call to zpool_prop_init() in there anywhere, zpool_prop.c does not seem to be compiled as well; am I missing something obvious?

I *guess* it was done this way as it's the only FreeBSD-specific part in the "common" code, and everything using IN_BASE is located under sys/contrib/openzfs/lib/libzfs/os/freebsd and sys/contrib/openzfs/include/os/freebsd proper.