Pysolf won't start on one of my systems, possible Locale problem?

I am a pysolf -Freecell addict, and am having a problem with it failing to start on one of my machines (it runs fine on the others) All are running Debian Trixie + KDE, with the latest updates…

When I start it in KDE, I get the blinking icon in the task bar as expected when any program is started. It blinks for a few seconds then vanishes w/o the game starting.

As an experiment I tried starting it in Konsole, and got the following:

fancybox:~$ pysolfc
Traceback (most recent call last):
  File "/usr/games/pysolfc", line 28, in <module>
    init()
    ~~~~^^
  File "/usr/share/games/pysolfc/pysollib/init.py", line 51, in init
    locale.setlocale(locale.LC_ALL, '')
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

looking at locale.py, the relevant section around line 615 appears to be:

def getlocale(category=LC_CTYPE): 

   """ Returns the current setting for the given locale category as 
        tuple (language code, encoding). 

        category may be one of the LC_* value except LC_ALL. It 
        defaults to LC_CTYPE. 

        Except for the code 'C', the language code corresponds to RFC 
        1766.  code and encoding can be None in case the values cannot 
        be determined. 

    """ 
   localename = _setlocale(category) 
    if category == LC_ALL and ';' in localename: 
        raise TypeError('category LC_ALL is not supported') 
    return _parse_localename(localename) 

def setlocale(category, locale=None): 

    """ Set the locale for the given category.  The locale can be 
        a string, an iterable of two strings (language code and encoding), 
        or None. 

        Iterables are converted to strings using the locale aliasing 
        engine.  Locale strings are passed directly to the C lib. 

        category may be given as one of the LC_* values. 

    """ 
    if locale and not isinstance(locale, _builtin_str): 
        # convert to string 
       locale = normalize(_build_localename(locale)) 
    return _setlocale(category, locale) 

Trying to see what locale is set to, I get:

@fancybox:~$ locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME=en_BI.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Any idea what might be wrong? It used to work just fine, but I think a recent update did say something about locale…

ex-Gooserider

1 Like

I fed your post to Copilot and it gave a pretty reasonable sounding explanation. Your output showed:

LANG=en_US.UTF-8
LC_TIME=enBI.UTF-8
LC_ALL=

That LC_TIME=en_BI.UTF-8 is suspicious, en_BI, (Burundi English) isn’t a standard locale shipped with Debian, so glibc doesn’t know how to handle it. When Python tries to set LC_ALL to the system default, it hits that unsupported setting and throws locale.Error: unsupported locale setting.

The theory of why it worked before is a recent update may have regenerated or pruned locale definitions. If en_BI.UTF-8 was never valid, it may have been silently ignored before, but now Python enforces stricter checks.

How to fix:

  1. Check which locales are actually generated:
    locale -a

  2. Regenerate locales:
    Edit /etc/locale.gen and make sure you have:
    en_US.UTF-8 UTF-8
    Then run:
    sudo locale-gen
    sudo update-locale LANG=en_US.UTF-8

  3. Clean up the bad setting:
    Look in /etc/default/locale and ~/.bashrc, ~/.profile, or ~/.pam_environment for any line setting LC_TIME=en_BI.UTF-8. Remove or correct it.
    You can reset all LC_* variables to match LANG:
    sudo update-locale LC_ALL=en_US.UTF-8

  4. Test again:
    locale
    pysolfc
    If all LC_* values are consistent (en_US.UTF-8), PySol should launch normally.

Quick workaround: Before starting PySol, run:
LC_ALL=enUS.UTF-8 pysolfc

Good luck.

4 Likes

Thanks for your analysis @pdecker , it makes sense….

I think I know why the LC_TIME=enBI.UTF-8 is set to that… I want my system to use 24 hour time, not AM/PM, but en_US.UTF-8 insists on AM/PM. I’ve done a lot of searching and as best I can tell, there isn’t a way to make the machine consistently use 24-hour time, EXCEPT to change the Locale. (Some but not all programs let you individually set the time format…)

But LC_Time also sets the format for date, and I wanted to keep the standard US month/day format. en_BI.UTF-8 was the first Locale I could find that used both US date format and 24 hour time… It was also one of the ones offered in KDE system settings which is where I got it…

Frustrating…. I don’t know why they can’t just have a check box for picking which time format to use.

ex-Gooserider

3 Likes

You can add formatting to the date command. That will only control the way it displays, not the way the system keeps date and time.

2 Likes

I always seem to have to choose AM/PM even though I have my timezone set to CST. This is in Ubuntu 24.04 using Gnome.

1 Like

Well, I tried the workaround command suggested:

Didin’t work -

$ LC_ALL=enUS.UTF-8 pysolfc
Traceback (most recent call last):
  File "/usr/games/pysolfc", line 28, in <module>
    init()
    ~~~~^^
  File "/usr/share/games/pysolfc/pysollib/init.py", line 51, in init
    locale.setlocale(locale.LC_ALL, '')
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

Just out of curiosity, I tried locale-a, and cat local.gen and got the following (edited to trim out the non-en listings)

$ locale -a
C
C.utf8
en_US.utf8
POSIX

> $ cat /etc/locale.gen 
> # This file lists locales that you wish to have built. You can find a list 
> # of valid supported locales at /usr/share/i18n/SUPPORTED, and you can add 
> # user defined locales to /usr/local/share/i18n/SUPPORTED. If you change 
> # this file, you need to rerun locale-gen. 
> ….
> # en_AG UTF-8 
> # en_AU ISO-8859-1 
> # en_AU.UTF-8 UTF-8 
> # en_BW ISO-8859-1 
> # en_BW.UTF-8 UTF-8 
> # en_CA ISO-8859-1 
> # en_CA.UTF-8 UTF-8 
> # en_DK ISO-8859-1 
> # en_DK.ISO-8859-15 ISO-8859-15 
> # en_DK.UTF-8 UTF-8 
> # en_GB ISO-8859-1 
> # en_GB.ISO-8859-15 ISO-8859-15 
> # en_GB.UTF-8 UTF-8 
> # en_HK ISO-8859-1 
> # en_HK.UTF-8 UTF-8 
> # en_IE ISO-8859-1 
> # en_IE.UTF-8 UTF-8 
> # en_IE@euro ISO-8859-15 
> # en_IL UTF-8 
> # en_IN UTF-8 
> # en_NG UTF-8 
> # en_NZ ISO-8859-1 
> # en_NZ.UTF-8 UTF-8 
> # en_PH ISO-8859-1 
> # en_PH.UTF-8 UTF-8 
> # en_SC.UTF-8 UTF-8 
> # en_SG ISO-8859-1 
> # en_SG.UTF-8 UTF-8 
> # en_US ISO-8859-1 
> # en_US.ISO-8859-15 ISO-8859-15 
> en_US.UTF-8 UTF-8 
> # en_ZA ISO-8859-1 
> # en_ZA.UTF-8 UTF-8 
> # en_ZM UTF-8 
> # en_ZW ISO-8859-1 
> # en_ZW.UTF-8 UTF-8 
> …
> # en_US.UTF-8 UTF-8 
> 
> # generated by KDE Plasma Region & Language KCM 
> en_BI.UTF-8 UTF-8

I didn’t try the steps of changing the locale for time back to enUS.UTF-8 since that was the problem I was trying to fix by original change from it… Is it possible to edit the actual enUS.UTF-8 locale to switch it to 24 hour time? Or how do the locale files work to indicate things like time and date formats?

ex-Gooserider

1 Like

Did some more digging - following the reference in the locale.gen file, I got to what might be the actual local file… It seems to have stuff in it about time format, but can I change it without breaking things elsewhere? If I can change it, any pointers to where I can find guidance about HOW?

 :/usr/share/i18n/locales$ cat en_US
comment_char %
escape_char /

% This file is part of the GNU C Library and contains locale data.
% The Free Software Foundation does not claim any copyright interest
% in the locale data contained in this file.  The foregoing does not
% affect the license of the GNU C Library as a whole.  It does not
% exempt you from the conditions of the license if your use would
% otherwise be governed by that license.

% Locale for English locale in the USA

LC_IDENTIFICATION
title      "English locale for the USA"
source     "Free Software Foundation, Inc."
address    "https:////www.gnu.org//software//libc//"
contact    ""
email      "bug-glibc-locales@gnu.org"
tel        ""
fax        ""
language   "American English"
territory  "United States"
revision   "1.0"
date       "2000-06-24"

category "i18n:2012";LC_IDENTIFICATION
category "i18n:2012";LC_CTYPE
category "i18n:2012";LC_COLLATE
category "i18n:2012";LC_TIME
category "i18n:2012";LC_NUMERIC
category "i18n:2012";LC_MONETARY
category "i18n:2012";LC_MESSAGES
category "i18n:2012";LC_PAPER
category "i18n:2012";LC_NAME
category "i18n:2012";LC_ADDRESS
category "i18n:2012";LC_TELEPHONE
category "i18n:2012";LC_MEASUREMENT
END LC_IDENTIFICATION

LC_CTYPE
copy "i18n"

translit_start
include "translit_combining";""
translit_end
END LC_CTYPE

LC_COLLATE

% Copy the template from ISO/IEC 14651
copy "iso14651_t1"

END LC_COLLATE

LC_MONETARY
int_curr_symbol     "USD "
currency_symbol     "$"
mon_decimal_point   "."
mon_thousands_sep   ","
mon_grouping        3
positive_sign       ""
negative_sign       "-"
int_frac_digits     2
frac_digits         2
p_cs_precedes       1
int_p_sep_by_space  1
p_sep_by_space      0
n_cs_precedes       1
int_n_sep_by_space  1
n_sep_by_space      0
p_sign_posn         1
n_sign_posn         1
%
END LC_MONETARY

LC_NUMERIC
decimal_point   "."
thousands_sep   ","
grouping        3
END LC_NUMERIC

LC_TIME
abday   "Sun";"Mon";"Tue";"Wed";"Thu";"Fri";"Sat"
day     "Sunday";/
        "Monday";/
        "Tuesday";/
        "Wednesday";/
        "Thursday";/
        "Friday";/
        "Saturday"

week 7;19971130;1
abmon   "Jan";"Feb";/
        "Mar";"Apr";/
        "May";"Jun";/
        "Jul";"Aug";/
        "Sep";"Oct";/
        "Nov";"Dec"
mon     "January";/
        "February";/
        "March";/
        "April";/
        "May";/
        "June";/
        "July";/
        "August";/
        "September";/
        "October";/
        "November";/
        "December"
% Appropriate date and time representation (%c)
d_t_fmt "%a %d %b %Y %r %Z"
%
% Appropriate date representation (%x)
d_fmt   "%m//%d//%Y"
%
% Appropriate time representation (%X)
t_fmt   "%r"
%
% Appropriate AM/PM time representation (%r)
t_fmt_ampm "%I:%M:%S %p"
%
% Appropriate date and time representation for date(1).  This is
% different from d_t_fmt for historical reasons and has been different
% since 2000 when date_fmt was added as a GNU extension.  At the end
% of 2018 it was adjusted to use 12H time (bug 24046) instead of 24H.
date_fmt "%a %b %e %r %Z %Y"
%
% Strings for AM/PM
%
am_pm   "AM";"PM"
END LC_TIME

LC_MESSAGES
yesexpr "^[+1yY]"
noexpr  "^[-0nN]"
yesstr  "yes"
nostr   "no"
END LC_MESSAGES

LC_PAPER
height   279
width    216
END LC_PAPER

LC_NAME
name_fmt    "%d%t%g%t%m%t%f"
name_miss   "Miss."
name_mr     "Mr."
name_mrs    "Mrs."
name_ms     "Ms."
END LC_NAME


LC_ADDRESS
postal_fmt    "%a%N%f%N%d%N%b%N%h %s %e %r%N%T, %S %z%N%c%N"
country_name "United States"
country_post  "USA"
country_ab2   "US"
country_ab3   "USA"
country_num   840
country_car   "USA"
country_isbn  0
lang_name     "English"
lang_ab      "en"
lang_term    "eng"
lang_lib    "eng"
END LC_ADDRESS

LC_TELEPHONE
tel_int_fmt    "+%c (%a) %l"
tel_dom_fmt    "(%a) %l"
int_select     "11"
int_prefix     "1"
END LC_TELEPHONE

LC_MEASUREMENT
% US customary units.
measurement 2
END LC_MEASUREMENT

Thanks,
ex-Gooserider

1 Like

Make a copy of the file before you attempt any changes. … then you can always restore it .
To make changes use a text editor… eg nano or vi.
Reboot after you make the changes.

I have no idea whether that file is the one you need to change… it is trial and error I am afraid.

This is what google AI says
" /usr/share/i18n/locales

is a directory on Linux-based systems that contains source files for locale definitions, which determine language and regional settings. These files are used by commands like localedef or locale-gen to generate locale data for the system, affecting how software displays dates, numbers, and other language-specific information. You can find a list of all available locale files in this directory using ls /usr/share/i18n/locales/*."

It does sound like that is the right file to change.

2 Likes

Making progress I think…

I did a Startpage search on “editing Locale files” and got an Instructables link: Making a Custom Locale to Change the Date Format : 4 Steps - Instructables

Interesting but it didn’t talk about the time format. However it led me to the more definitive Locale Helper: en_US which explained the strings and Locale Helper: Help page that gave me the definitions of all the formatting characters.

As best I can tell, it appears that %r specifies AM/PM format, and %R is 24 hour format.

After copying the original en_US to “en_US-original” I edited another copy and switched the three instances of %r I found in LC-time to %R and replaced the en_US with the edited version.

However so far I’m having problems getting the locale to update it so that I consistently get the en-US to stick… If I do ~ export LC_ALL=en_US.UTF-8 ~ export LC_TIME=en_US.UTF-8 in Konsole, then that tab shows the right result for locale, but none of the other tabs do.

Pysolf will start properly if I do it from that command line, but not from the menu or in any other tab… So that was the problem and I seem to have sort of fixed it. Not sure if it has fixed the time issue overall though.

I can’t find where that en_BI.UTF-8 is hiding… I checked all the spots @pdecker mentioned and either the file doesn’t exist, or doesn’t have any LC entries in it…

Frustrating, though educational…

ex-Gooserider

3 Likes

It seems that it is not exporting the setting properly.
Maybe put the setting in .bashrc … then it would apply to all shells

When you type something like that into the edit window, put it inside backquotes
`~export LCALL=enUS.UTF-8`
then it will come out as typed
~ export LCALL=enUTF-8
The backquotes protect it from having discourse interpret the special characters

2 Likes

I have gone full nuclear on it before and done something like:

sudo su -
cd /
find . | grep -i "en_BI.UTF-8"

You may get a few results that don’t matter but you also may find the ultimate cause.

2 Likes