-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arch Linux Crash on open, when open no books... #1161
Comments
It looks like you have misconfigured your system's locale. What do you have as the output of these commands? $ localectl
$ grep -vE '^#' /etc/locale.gen |
These are the results you asked of me:
The problem still occurs. I have tried uninstalling, rebooting, reinstalling. Didn't fix the issue. |
I don't think your locales are formatted right. First I would edit your
Then regenerate locales: $ sudo locale-gen Next use that as your system locale: $ sudo localectl set-locale en_IL.UTF-8 That should stick after a reboot, but I'd double check anyway with If that doesn't work, can you additionally check that Xiphos does cooperate with an en_US locale: $ env LANG=en_US.UTF-8 xiphos |
My
There is no period. Is the program expecting to find a period seperated entry? Will modifying the entry by adding a period affect the system adversly? edit:
https://www.guyrutenberg.com/2016/04/16/en_il-english-locale-for-israel/
Further down on the page:
Clearly shows the period in the developers listing. Why does my |
Not only is the entry not a correct match for the current locale database, it is also commented out (the leading Your locale.gen file has obviously been edited from the original if it only has that one commented out line. Also that may have been the right format at one point, but it is not any more. The entries must match what the database records them as for it to work. The
No. Having the correctly formatted locale entries and a regenerated locale cache will onyl make everything else work better too. There are probably localization things broken and reverting to the generic |
By the way if you don't use any other locales you can safely nuke everything in
The vast majority of stuff in that file is just commented out possible entries people might want to use. You do not need anything at all in the file except the locales you really want to use. For example all my systems have this: $ cat /etc/locale.gen
en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8
tr_TR.UTF-8 UTF-8 That's it, and those are locales I actually want any programs on my system to be localized in. Ones that don't support those locales will fall back to something they do support anyway. Of course if you do use any other locales be sure to keep their respective lines. All the rest can go. And don't forget to run Also by the way one you have the locale you want generated properly, don't forget to set the matching entry as your system default: $ sudo localectl set-locale en_IL.UTF-8 Then reboot for it to take effect as the system default and inherited in newly spawned shells and apps. |
I have a fresh install, which only has about one month of use. I don't alter these files. |
|
Looks like my installer is causing the locale issue. I will enable the version you suggest to see if it fixes the issue then, if you think I should move the discussion to Calamares github, will do. |
Okay now we're getting somewhere! So first of all there was some miscommunication. You said "contains this entry […] There is no other choice", by which I understood that was the only line in the file. In retrospect I assume you mean "the only line related to en_IL", but that is where I assumed you must have edited the file because by default it contains a large list of mostly commented possible entries. Second, there is clearly a bug in Calamares. This is the first time I've even heard of that installer. There is certainly nothing wrong with using a 3rd party installer especially since Arch Linux doesn't even officially have a graphical installer. But it does mean this is is not an Arch Linux bug, it's a big in the installer. I would definitely raise this as an issue on their tracker (wherever that is). The installer should be placing well formed locales according to the current glibc version's locale database. Third, that still leaves something in the way of Xiphos bugs or at least undesirable behavior.
I'd say we should keep this issue open to track fixing those 3 related things in Xiphos, but again definitely do raise an issue to track the problem with Calamares separately. |
P.S. It looks like Calmares has an issue tracker here. |
Add one more action item to my list:
|
I like that idea. Maybe rename "Special Locale" to just "Locale" and change "None" to "System Default"? Might be worth its own issue. |
There were other issues with the application, like, Strong's Concordance wouldn't function when clicking a number. There must have been a bad update from one of the dependencies, glibc or such. I'm not sure when exactly, but it was involving multiple applications not just Xiphos. I have solved the issue by reinstalling the OS. There is one exception though, WLC module and OSHB Module, though correctly loaded when looking in the .sword folders, show squares instead of Fonts. |
I have solved the issue by reinstalling the OS. |
Opening Xiphos with Terminal I get this error...
Program is unusable.
`$ xiphos
(process:10842): Gtk-WARNING **: 11:23:21.304: Locale not supported by C library.
Using the fallback 'C' locale.
Fontconfig warning: ignoring LC_CTYPE=C;LC_NUMERIC=en_IL;LC_TIME=en_IL;LC_COLLATE=C;LC_MONETARY=en_IL;LC_MESSAGES=C;LC_PAPER=en_IL;LC_NAME=en_IL;LC_ADDRESS=en_IL;LC_TELEPHONE=en_IL;LC_MEASUREMENT=en_IL;LC_IDENTIFICATION=en_IL: not a valid region tag
Segmentation fault (core
dumped)
The text was updated successfully, but these errors were encountered: