Bug 2104907

I can reproduce this if I install glibc-all-langpacks and remove glibc-langpack-en.

This ended up being an issue with the locale definition itself, rather than all-langpacks in specific. The localedata/SUPPORTED entry (and corresponding in-dist-git-tree SUPPORTED file entry) for the en_US@ampm needs a fix-up.

Ideally, we want `locale -a' to show two @ampm locales for en_US, both using the UTF-8 charset but one mentioning it explicitly (this is in line with how `locale -a' lists other locales). We originally documented that en_US@ampm is UTF-8 when releasing the @ampm locale. From bug 2000374 doc text:

".New UTF-8 locale `en_US@ampm` with 12-hour clock

With this update, you can now use a new UTF-8 locale `en_US@ampm` with a 12-hour clock. This new locale can be combined with other locales by using the `LC_TIME` environment variable."

The entries we want are:

* en_US@ampm, using UTF-8 as an implicit default charmap
* en_US.utf8@ampm, explicitly mentioning UTF-8

A good test code fragment:

function testlocale ()
{
  if locale -a | grep -q "^${1}$"; then
    echo PASS: Locale "$1": available
  else
    echo FAIL: Locale "$1": missing
  fi
  CHRMP=$(LC_ALL="$1" locale charmap)
  if [ "$CHRMP" == "UTF-8" ]; then
    echo PASS: "$1" is UTF-8
  else
    echo FAIL: "$1" is "$CHRMP" instead of UTF-8
  fi
}
testlocale en_US.utf8@ampm
testlocale en_US@ampm

This should pass in two cases:
1. glibc-langpack-en is installed but glibc-all-langpacks is NOT installed
2. glibc-all-langpacks is installed but glibc-langpack-en is NOT installed

Of course, setting LC_TIME to the same locale names should lead to `date' showing AM/PM time instead of 24h time. Again, for both langpack RPMs separately installed.

The fix we need is:

--- a/SUPPORTED
+++ b/SUPPORTED
@@ -159,7 +159,8 @@ en_SG/ISO-8859-1 \
 en_US.UTF-8/UTF-8 \
 en_US/ISO-8859-1 \
 en_US.ISO-8859-15/ISO-8859-15 \
-en_US/UTF-8 \
+en_US@ampm/UTF-8 \
+en_US.UTF-8@ampm/UTF-8 \
 en_ZA.UTF-8/UTF-8 \
 en_ZA/ISO-8859-1 \
 en_ZM/UTF-8 \

Basically, the locale name should be in the format:
language[_territory[.codeset]][@modifier]
(https://www.gnu.org/software/libc/manual/html_node/Locale-Names.html)

With this fix, it would be good to include tests for the 'ampm' locales as well as a general sanity check for all shipped locales. I've been expanding on the test I wrote above in comment 3, and I've come up with this:

#!/bin/bash

function checklocale ()
{
  if locale -a | grep -q "^${1}$"; then
    echo PASS: Locale "$1": available
  else
    echo FAIL: Locale "$1": missing
  fi
}

function testlocale ()
{
  CHRMP=$(LC_ALL="$1" locale charmap)
  if [ "$CHRMP" == "UTF-8" ]; then
    echo PASS: "$1" is UTF-8
  else
    echo FAIL: "$1" is "$CHRMP" instead of UTF-8
  fi
  DATE=$(LC_TIME="$1" date)
  if echo $DATE | grep -q '\s[AP]M\s'; then
    echo PASS: "$1" shows AM/PM time
  else
    echo FAIL: "$1" does not show AM/PM time
  fi
}

# Make sure these two locales are definitely present
checklocale en_US.utf8@ampm
checklocale en_US@ampm

# Test *any* ampm locales found on the system for charmap and date
for l in $(locale -a | grep 'en_US.*@ampm'); do
  echo
  echo "Testing locale $l"
  testlocale $l
done

# Test *all* locales on the system for setlocale
cat > test-setlocale-with-locale-a.c <<EOF
#include <locale.h>
#include <stdio.h>

int
main (int argc, char *argv[])
{ 
  char *locale = argv[1];
  int fail = 0;

  for (int i = 0; i < 13; i++)
    if (!setlocale(i, locale))
      fail = 1;

  return fail;
}
EOF
gcc -o test-setlocale-with-locale-a test-setlocale-with-locale-a.c
for l in $(locale -a); do
  if ./test-setlocale-with-locale-a $l; then
    echo "PASS: setlocale ($l) passed"
  else
    echo "FAIL: setlocale ($l) failed"
  fi
done

And this should be tested with:
(1) glibc-langpack-en installed
(2) glibc-all-langpacks installed and *no* glibc-langpack-* packages installed at the time.

Even though the 'ampm' specific bits are RHEL-8-only, testing setlocale for all shipped locales with various common langpacks installed is a good sanity check for other/newer releases as well.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (glibc bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7684

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days