typos.

In D18297#388056, @pfg wrote:

I am not an expert on the area but I see where the comment comes from:

RFC3629 states on page 2:

The byte-value lexicographic sorting order of UTF-8 strings is the
same as if ordered by character numbers. Of course this is of
limited interest since a sort order based on character numbers is
almost never culturally valid.

The Boyer-Moore fast search algorithm can be used with UTF-8 data.

redo.

There's a reply and action upstream, the patch integrated there is more complete (removing all "bits" stuff from mansearch), will use that one.

Baptiste, anything else you want to see done/answered for this to proceed?

In D17449#375265, @yuripv wrote:

In D17449#375264, @bapt wrote:

First we should ship the said manpage :)

I think this is debattable, but I think upstream is opened enought to accept such change, you should anyway talk to them to see if that will remain a freebsd only patch or not :)

OK, will do.

In D17842#382775, @bapt wrote:

That look sane to me, the thing is I wonder how hard it would be to maintain

I think this makes perfect sense. You might want to update editline(3) as well so it doesn't say it only knows about UTF-8 and C locales.

cleanup done separately; rebase

Just for the note: perl bits here are only the helper tools for someone updating the locale sources in share/, and aren't run during the build, so even if something is broken there (and I tried not to as I used them), it's only bad until there's a need to update the data again where they will be fixed anyway :)

Do I need explicit approval from @gnn here?

In D17531#378698, @araujo wrote:

Hi @yuripv , is there anything pending for this patch to be committed?

I have updated the suite to pass everything that is enabled, still having tz tests disabled as there's no easy way to make them pass and our parsing code is rudimentary compared to netbsd's one.

Can I proceed with kib being the reviewer for this, or bhyve group will take a look?

rebase on top of recent localedef changes; make the change less intrusive keeping the warning and only stripping "print" from "space|control" combination.

rebase after the fix for PR231653 landed separately

With this change alone (and that's what it actually looked for mips) collation is broken. The changes *and* the amount of conversion we need to do every time we load the collation tables make this way not worth it IMO.

In D17618#376157, @sbruno wrote:

In D17618#376145, @yuripv wrote:

Sean, could you please give this a try on ref12-ppc64?

You would like me to revert D17603 and apply this singular diff?

Sean, could you please give this a try on ref12-ppc64?

In D17603#376086, @emaste wrote:

FWIW I have a small preference for maintaining the approach taken in rS308170 but extending/fixing it for all archs - have the on-disk data in a consistent endianness. See the progression of pwd_mkdb ending with commits rS332902, rS333133 (D15144).

issue fixed (wchar_t, that is (unsigned) int, is *4* bytes).

In D17603#376016, @yuripv wrote:

In D17603#376009, @sbruno wrote:

In D17603#375981, @yuripv wrote:

In D17603#375980, @sbruno wrote:

In D17603#375978, @yuripv wrote:

In D17603#375975, @sbruno wrote:

I'll apply this to the fbsd cluster build.

The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?

I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.

Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?

Thank you!

Ok, I've only updated the ref12-ppc64 jail and I zfs snapshotted it as well in case we want to to rollback. Take a look around and see if it seems "fine"

Yes, it seems to be fine (tmux works now, as well as basic collation test program).

In D17603#376009, @sbruno wrote:

In D17603#375981, @yuripv wrote:

In D17603#375980, @sbruno wrote:

In D17603#375978, @yuripv wrote:

In D17603#375975, @sbruno wrote:

I'll apply this to the fbsd cluster build.

The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?

I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.

Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?

Thank you!

Ok, I've only updated the ref12-ppc64 jail and I zfs snapshotted it as well in case we want to to rollback. Take a look around and see if it seems "fine"

In D17603#375980, @sbruno wrote:

In D17603#375978, @yuripv wrote:

In D17603#375975, @sbruno wrote:

I'll apply this to the fbsd cluster build.

The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?

I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.

Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?

In D17603#375975, @sbruno wrote:

I'll apply this to the fbsd cluster build.

The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?

complete rework

no debug printfs