You are not logged in.
rbh wrote:"Released", for me, is when a package is pushed to the repository. Still in repo is version 4.2.1+bl10-1 (5/22/2020) https://www.bunsenlabs.org/repoidx.html … ium-jgmenu
There is a release (noun) on GitHub but it isn't released (verb) on BunsenLabs repo. Do tell me how I can phrase it better. Technical terms can be inconsistent between us, and it is always good to clear things up.
Github is a tool to work with the source for an application. When you are ready to make an installable deb, you can say that you release the source. But on https://github.com/BunsenLabs/jgmenu/bl … um/NEWS.md, there is no release info for version 4.3, so not either the source is released, even if it is available.
Yes. I am awaiting final release, so as to safeguard the final release with one more precautionary step.
But if you have aplied the fix, jgmenu should not be broken for you now...
I have NOT followed the Debian guide for locales as it is NOT a typical end-user would do. I repeat that I act as an end user for this patching process as best as I can. For whether this problem is rare, perhaps install your own BunsenLabs with Hong Kong locales. Interesting to see if this problem occurs.
I started one vm I installed in august, but not yet logged in to and done postinstallation tweaks on. When I ran "dpkg-reconfigure locales", I could choose between all hundreds of locales. If you have not installed and run "localepurge", then there is something wrong with your installation.
(edit: As you wrote you could only choose en_HK.UTF-8)
Can you not see that? I do not think that there will be any differense if I choose locales for Hongkong, but I will test. Just now my desktop is down, due to change to change to an "raise and lower data table"
Last edited by rbh (2021-01-04 15:58:24)
// Regards rbh
Please read before requesting help: "Guide to getting help", "Introduction to the Bunsenlabs Lithium Desktop" and other help topics under "Help & Resources" on the BunsenLabs menu
Offline
After some experimentation, I discovered that LANG=en_HK is fine for jgmenu, LANG=en_HK.iso88591 is fine as well, but en_HK.utf8 is not compatible with jgmenu. Given that Hong Kong uses both English and Chinese, UTF8 usage makes total sense. XSupportsLocale() may return false for en_HK.utf8, meaning X11 does not support this locale. In old versions of jgmenu, it just treats this as a warning, and proceeds to not work properly. In jgmenu 4.3.0 however, it seems like it falls back to LANG=C for unsupported locales.
@rbh, I'm sorry but Hongkongers must use UTF8 and when programs fail to accommodate, it shouldn't be our problem. You could say that we have the trickiest locale to support though and that we are the "destroyer of Linux harmony", haha, such a title for us. But I must thank you for reminding me that installing en_HK non-UTF8 locale and setting that as a system default irons out the problems if no patching is available.
@malm what are your thoughts on this? Am I correct as to why this fix works?
@{any software developers somehow reading this} I hope that your program can support locales properly. It is, as Tom Scott mentions in Computerphile's video regarding internationalization, extremely troublesome. Don't be exhausted, though. Many users around the world will silently thank your effort.
Offline
But "LANG=en", is not a valid locale @evnchn!
With the command "dpkg-reconfigure locales", it is not possible to add "LANG=en", to /etc/locale.gen. You wrote before, that you could only choose en_HK.utf8, have you not used "dpkg-reconfigure locales", but instead directly edited /etc/locale.gen?
Valid locales is listed in /usr/share/i18n/SUPPORTED. It contains 495 locales. If your /etc/locale.gen only contains your chosen locales, will the command "dpkg-reconfigure locales", add all the disabled locales after your chosen.
It does not make sense what you are writing and often you do not answer questions.
Last edited by rbh (2021-01-05 09:44:14)
// Regards rbh
Please read before requesting help: "Guide to getting help", "Introduction to the Bunsenlabs Lithium Desktop" and other help topics under "Help & Resources" on the BunsenLabs menu
Offline
Some programs disagree on how to write UTF8.
For example, on my system:
john@lithium:~$ echo $LANG
en_GB.UTF-8
LightDM's greeter, on the other hand, writes in ~/.dmrc:
Language=en_GB.utf8
This difference between UTF-8 and utf8 is enough to break correct locale displays, and is a long-standing issue with LightDM: https://bugs.debian.org/cgi-bin/bugrepo … bug=679386
( BunsenLabs ship a small Xsession script to work around it: https://github.com/BunsenLabs/bunsen-co … tdm-locale )
Does LANG=en_HK.UTF-8 possibly work for you?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
But "LANG=en", is not a valid locale @evnchn!
I ran "locale -a" and the choices are C, C.UTF-8, en_HK, en_HK.iso88591, en_HK.utf8 and POSIX. I didn't say LANG=en is valid locale. In fact LANG=en jgmenu_run causes falling back to C. Please read carefully
With the command "dpkg-reconfigure locales", it is not possible to add "LANG=en", to /etc/locale.gen. You wrote before, that you could only choose en_HK.utf8, have you not used "dpkg-reconfigure locales", but instead directly edited /etc/locale.gen?
I edited nothing back when I can only choose en_HK.utf8 and it is the default after I finished BL USB install. I never edited /etc/locale.gen manually.
Valid locales is listed in /usr/share/i18n/SUPPORTED. It contains 495 locales. If your /etc/locale.gen only contains your chosen locales, will the command "dpkg-reconfigure locales", add all the disabled locales after your chosen.
It does not make sense what you are writing and often you do not answer questions.
I have difficulty understanding this last paragraph.
Offline
Does LANG=en_HK.UTF-8 possibly work for you?
LANG=en_HK.utf8 jgmenu_run
LANG=en_HK.utf-8 jgmenu_run
LANG=en_HK.UTF8 jgmenu_run
LANG=en_HK.UTF-8 jgmenu_run
These all fail (as in they cause the same errors as running jgmenu alone. Check previous posts for detail)
Last edited by evnchn (2021-01-05 10:58:53)
Offline
I have now installed new VM with "en_HK.UTF-8 UTF-8", set in /etc/locales.gen.
@malm and @evnchn, I can confirm that when jgmenu i run from terminal, it gives the error
warning: XSupportsLocale(): error setting locale
warning: XSetLocaleModifiers(): error setting locale
and it kraches with segmentfault when pointing to most submenus.
Adding en_GB.UTF-8 and logging in with those locales, makes jgmenu stable and produces no errrors when started from terminal.
Relogin with en_HK.UTF-8, makes jgmenu crach.
Cloning jgmenu and installing the updated jgmenu to $HOME/bin, logged in choosing en_HK.UTF-8, the menu is stable.
Command "echo $LANG" returns "C".
Logged in with locale en_GB.UTF-8, command "echo $LANG", returns en_GB.UTF-8
Logged in with en_HK.UTF-8, killing jgmenu and starting it with
LANG=en_GB.utf-8 /usr/bin/jgmenu_run
,
gives also a working jgmenu.
// Regards rbh
Please read before requesting help: "Guide to getting help", "Introduction to the Bunsenlabs Lithium Desktop" and other help topics under "Help & Resources" on the BunsenLabs menu
Offline
Nice. We all know what is happening now. Thanks. I'll wait for 4.3.0 to come on repo regardless. Thanks
Offline
I ran "locale -a" and the choices are C, C.UTF-8, en_HK, en_HK.iso88591, en_HK.utf8 and POSIX.
You do not choose locales with the command "locale -a". You list what's default/you have chosen to install. To choose another locale, you run "dpkg-reconfigure locales".
I didn't say LANG=en is valid locale.
I misread the first sentence in post #42.
rbh wrote:You wrote before, that you could only choose en_HK.utf8, have you not used "dpkg-reconfigure locales", but instead directly edited /etc/locale.gen?
I edited nothing back when I can only choose en_HK.utf8 and it is the default after I finished BL USB install. I never edited /etc/locale.gen manually.
Again: After standard installation, you have to run "dpkg-reconfigure locales", to add other locales. I have asked you if you did not do that. You answered not. But if you have not edited /etc/locale.gen (and run "locale-gen"), or run "dpkg-reconfigure locales", then you have not tried to change locales! You wrote you could not change.
You can also add more locales when installing, if you choose "Advanced installation"
rbh wrote:Valid locales is listed in /usr/share/i18n/SUPPORTED. It contains 495 locales. If your /etc/locale.gen only contains your chosen locales, will the command "dpkg-reconfigure locales", add all the disabled locales after your chosen.
It does not make sense what you are writing and often you do not answer questions.I have difficulty understanding this last paragraph.
Ok, i understand now, that you have ignored some of what I've written and have misunderstood some basicks.
File /usr/share/i18n/SUPPORTED, contains all supported locales. They are also found in /etc/locale.gen, but there is all disbled locales preceeded with *. All enabled locales and default even C, C.UTF-8 and POSIX, is listed with command "locale -a".
If you have been forced to create and edit /etc/locale.gen from scratch, it contains only the locales you have chosen. If you add one locale listed in /usr/share/i18n/SUPPORTED and run locale-gen, the /etc/locale.gen, will only contasin you8r chosen locales.
If you run "dpkg-reconfigure locales", all the rest of locales from file /usr/share/i18n/SUPPORTED, will be addes as disabled in /etc/locale.gen.
Last edited by rbh (2021-01-05 15:55:42)
// Regards rbh
Please read before requesting help: "Guide to getting help", "Introduction to the Bunsenlabs Lithium Desktop" and other help topics under "Help & Resources" on the BunsenLabs menu
Offline
@evnchn, the new jgmenu package is now out for Lithium (armhf, amd64, i386)
Offline
@malm works. This issue is totally solved
Offline