Menulibre crashing

nhazadian · 25 December 2025 14:50

It works on my laptop, but on this PC I get:

= menulibre
Traceback (most recent call last):
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 1651, in do_activate
self.win = MenulibreWindow(self, headerbar)  # type: ignore
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 82, in **init**
self.configure_application_actions()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 342, in configure_application_actions
label=_(‘Add _Launcher…’),
~^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: ‘locale’ codec can’t decode byte 0xe2 in position 13: decoding error

The fact that it works on my laptop suggests it is a data-dependent thing.

Some menu entries which used to be in order, are no longer.

Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text

linux-aarhus · 25 December 2025 15:09

The error message indicates a locale configuration issue on this particular system, since it fails in when trying to assign a translation to a property.

I cannot guess where, what or why.

Try loading the application

LANG=C menulibre

If that work - may run localectl set-locale <your-locale> e.g. for an english system in Denmark

localectl set-locale en_DK.UTF-8

The configuration file you will be changing is /etc/locale.conf.

Do remember that the given locale must be configured in etc/locale.gen and the locale must have been created by running locale-gen.

The issue may have surfaced if a /etc/locale.gen.pacnew was used to overwrite the existing file.

nhazadian · 25 December 2025 16:20

Afraid that doesn’t do it. Here’s my /etc/locale.conf:

= cat /etc/locale.conf
LANG=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_TIME=en_US.UTF-8

Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text

linux-aarhus · 25 December 2025 16:30

It is a python error and the message is the trace back.

It points to an error in data file - as it is the i18n module one could suspect one of the mo files gone haywire - but it is impossible to say.

anon33601770 · 25 December 2025 18:27

regarding this from the previous post:

What is the result of:
grep -v ^# /etc/locale.gen

?
Are the needed locale present?
(this lists all activated locale - but they must also have been generated after a change to that file)

nhazadian · 25 December 2025 20:05

= grep -v ‘^#’ /etc/locale.gen
de_CH.UTF-8 UTF-8
de_CH ISO-8859-1
en_US.UTF-8 UTF-8
en_US ISO-8859-1
fr_CH.UTF-8 UTF-8
fr_CH ISO-8859-1

Last time, free of charge </> button

Yochanan · 25 December 2025 20:56

Please stop using quotes for terminal output.

Hint: Did you see the edits?

nhazadian · 26 December 2025 00:14

Ah, no I didn’t. If you work at it you could make the text even smaller.

Sorry about that. I thought the quotes looked pretty good, but I’ll follow protocol in the future.

Yochanan · 26 December 2025 05:00

No worries. Sorry, I know I could have communicated better regarding the subject. It’s just hard to help if it’s hard to read.

linux-aarhus · 26 December 2025 06:04

I think your problem is right there.

Please comment the lines with ISO-8859-1 - only keep those ending in UTF-8 - like this - save the file and run sudo locale-gen.

de_CH.UTF-8 UTF-8
#de_CH ISO-8859-1
en_US.UTF-8 UTF-8
#en_US ISO-8859-1
fr_CH.UTF-8 UTF-8
#fr_CH ISO-8859-1

Many years ago when I volunteered to rewrite pacman-mirrors application I encountered this exact issue.

Python 2 was ASCII and Python 3.x has been defaulting unicode for quite a while - the encoding header (shown below) that was once necessary, is no longer as relevant as it was - in this case - if the developers of menulibre had included the encoding header you may not have seen the issue at all.

# -*- encoding: utf-8 -*-

But, my thought is, due to you having the ASCII locales enabled, Python is chocking on chars which is not in the ASCII charset (256 chars).

nhazadian · 26 December 2025 08:24

= sudo locale-gen
Generating locales…
de_CH.UTF-8… done
en_US.UTF-8… done
fr_CH.UTF-8… done
Generation complete.
= menulibre
Traceback (most recent call last):
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 1651, in do_activate
self.win = MenulibreWindow(self, headerbar)  # type: ignore
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 82, in init
self.configure_application_actions()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 342, in configure_application_actions
label=_(‘Add _Launcherâ¦’),
~^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: ‘locale’ codec can’t decode byte 0xe2 in position 13: decoding error

Mod edit -- I trust this text is large enough:

Please use expected formatting for all code or command output, which must be paced in a pre-formatted text container.

For simple inline code follow this example code here.

For multi-line command output place text beween two rows of three (```) backtick characters forming a scrollable text box or use the </> button in the Compose window:
What is a Quark?

A. In Physics, an elementary particle and fundamental constituent of matter. 
B. A character from the Star Trek: "Deep Space Nine" television series.
C. A soft, creamy, usually unsalted cheese traditional to central Europe.
Corrected for you. No charge.
See How to Post Command Output as Preformatted Text

anon33601770 · 26 December 2025 09:22

You should probably at least log out and back in again
or reboot the machine
to see the effects.

linux-aarhus · 26 December 2025 11:12

The message is well-known and documented with Python language and it is caused by an invalid byte sequence when trying to decode the content.

I have had to deal with unwanted BOMs on numerous occasions.

Why it occurs on one system and not another is impossible to guess, I guess the ASCII locale - it was not them.

I have synced menulibre to one of my test systems and menulibre launch without issues - so now I suspect that one of your desktop files, read by menulibre, is a fault.

Still guessing - it could be a BOM (Byte Order Mark) which may be set as the first character of a file.

Try to recall a situation where you may have edited a .desktop file with an advanced editor. This editor may have added the BOM as the first character and if/when menulibre expects text-only - thus it may break if the BOM exist.

Unless you have edited .desktop files in /usr/share/applications manually then we can rule those out.

Locate any .desktop files in your user’s home folder

find ~/ -name '*.desktop'

Only you know which one you edited.

Open the file using the nano editor - look at the very first character - if it looks weird - like a control character - delete it and save the file.

nhazadian · 26 December 2025 11:36

I did use the </> thingy. I added the bolding because that’s how it looks on my terminal; makes it easier to read.

Since my preformatted text has no leading spaces and there’s no formatting to speak of, there’s not much difference aside from the font anyway.

nhazadian · 27 December 2025 10:47

I came up with over 160 possible files. Sorting by mod time, everything within the past few months was OK. Maybe I need to look at more.

nhazadian · 27 December 2025 10:48

Rebooting hasn’t helped.

linux-aarhus · 27 December 2025 11:19

The reason for crashing is clear - it is a decoding error.

Under which circumstance it occur is unclear.

The traceback provides an idea of what can go wrong.

Since it appears in function that assigns a translated label to an action, it points to the translation files provided for the current UI language.

I don’t know what your primary UI language but since I cannot make it fail on a system with English locale en_DK.UTF-8 - I have to think it is either the de_CH or the fr_CH locale.

Switch locale to en_US
```
localectl set-locale en_US.UTF-8
```
Then restart your system and test by launching menulibre from the command line.
Since this the default language for the application expect it to run without issues.
If it fails to run - quite unexpected - then you may have file system errors, affecting the application.
Switch the current locale to de_CH
```
localectl set-locale de_CH.UTF-8
```
Then restart your system and test once again
Test the last locale fr_CH
```
localectl set-locale fr_CH.UTF-8
```
Restart your system and test one more time

If you can run menulibre using one locale but not another then you have narrowed the issue to that locale’s translation files and - combined with the traceback you provided earlier - is information you can use to open an issue with the developer(s) of menulibre.

Besides this I have no more to contribute but suggesting you create an issue at GitHub - bluesabre/menulibre: MenuLibre is an advanced menu editor that provides modern features in a clean, easy-to-use interface..

nhazadian · 28 December 2025 15:10

**= cat /etc/locale.conf**
LANG=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_TIME=en_US.UTF-8
**= menulibre**
Traceback (most recent call last):
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 1651, in do_activate
self.win = MenulibreWindow(self, headerbar)  # type: ignore
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 82, in **init**
self.configure_application_actions()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
File “/usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py”, line 342, in configure_application_actions
label=_(‘Add _Launcher���’),
~^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: ‘locale’ codec can’t decode byte 0xe2 in position 13: decoding error

I’ve also checked each of the 165 .desktop files, with no sign of a funky first character.

Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text

linux-aarhus · 28 December 2025 15:46

Your error message displays - note the highlighted line

The highlighted line contains three (3) characters which is not in the source nor on my system so I am fairly certain those chars is causing the UnicodeDecodeError.

I didn’t recognise it earlier though it has been there all the time

If you ask me how it has happened - I have no idea - a fairly common cause is file system corruption of some sort.

But you could look at the file data - especially Modify and Access properties - my ideas would be guessing

stat /usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py

On my system line 338..345 in /usr/lib/python3.13/site-packages/menulibre/MenulibreApplication.py read

        # Add Launcher
        self.actions['add_launcher'] = Gtk.Action(
            name='add_launcher',
            # Translators: Add Launcher action label
            label=_('Add _Launcher…'),
            # Translators: Add Launcher action tooltip
            tooltip=_('Add Launcher…'),
            stock_id=Gtk.STOCK_NEW)

The upstream source read the same - albeit not exactly the same lines

github.com/bluesabre/menulibre

menulibre/MenulibreApplication.py

master


      
          # Add Launcher
          self.actions['add_launcher'] = Gtk.Action(
              name='add_launcher',
              # Translators: Add Launcher action label
              label=_('Add _Launcher…'),
              # Translators: Add Launcher action tooltip
              tooltip=_('Add Launcher…'),
              stock_id=Gtk.STOCK_NEW)

your options

Start your system on a live USB and run a file system check on your root partition
Remove the application from your system and install it again
Edit the file by hand and bring the content in line with the original

In any case I strongly recommend to boot on a live ISO and check the file system’s consistency.

anon33601770 · 28 December 2025 16:00

That was my guess as well, but it is simply because of the editor he used to post this here
(the forum editor - there is a choice between two variants by clicking the leftmost icon).

The initial post shows the same snippet, but differently formatted - those are just three dots.

If there is an issue with that file for some reason, wouldn’t it make sense to uninstall the application, clear the package cache to force a re-download of a fresh copy and then reinstall the application?

ps:
ah - that was one of your options as well