poudriere-devel's implicit LC_COLLATE use (a default): does it mix well with python3?

From: Mark Millard via freebsd-ports <freebsd-ports_at_freebsd.org>
Date: Sat, 02 Oct 2021 04:52:28 UTC
I've a case of my poudriere-devel builds of www/chromium in
python code that is executing but the builds on the FreeBSD
servers do not get the error.

This lead me to look at my log vs. one from the servers
and I found a difference that I think might change python
behavior, not that I've proved that the specifics are
involved in my issue. (The bulk -a with the failure still
has days to go.)

From what I read locale.strcoll(string1,string2) and
locale.strxfrm(string) are based on LC_COLLATE. From
what I gather, for python3, this LC_COLLATE assignment
may be rather unusual (i.e., not some UTF mode). (I do
not claim to have found all uses of LC_COLLATE, just
a couple of examples.)

The difference is having the LC_COLLATE assignment, as
shown in the log from my build but not in the one from
the FreeBSD servers that I looked at (that bulk -a also
still running). My log shows:


LC_COLLATE=C seems to be from:

. . .

: ${HTML_TYPE:=inline}

if [ -n "${MAX_MEMORY}" ]; then
        MAX_MEMORY_BYTES="$((MAX_MEMORY * 1024 * 1024 * 1024))"
. . .

in /usr/local/share/poudriere/common.sh from
poudriere-devel (i.e., the main branch). The two
LC_COLLATE lines are not in the release branch
that I looked at.

Eventually I'll probably test if this is involved in my context's
failure, unless I figure out something else that might make the
difference first.

Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)