Bug 466117

Hello,


Put it another way:

By *default*, on a Romanian-enabled system with an American physical keyboard, pressing:

- AltGr + s
- AltGr + t
- AltGr + Shift + s
- AltGr + Shift + t

should generate correct *comma-below* characters in any application, including system console ( *not* cedilla-below characters).

The same *default* result should be obtained pressing specific keys on a hardware Romanian keyboard.


Thanks a lot,
Răzvan

Răzvan, I fail to see the problem. Is the comma not default ?

Also please fill a bug on anaconda, in text mode installation there's still the ro_win keyboard only instead of these 4.

system-config-language is not dealing with /etc/sysconfig/keybord, it deals with /etc/sysconfig/i18n only

assigning bug to anaconda(In reply to comment #0)
> Expected results:
> 
> Setting "Romanian" with the system-config-language utility should install
> correct entries and packages for Romanian ("secondary" keyboard layout,
> comma-below characters and an appropriate system font).
if system-config-language not installing required packages for Romanian, then we should update comps file Romanian group, need to file bug against comps

reassigning bug to anaconda

What exactly is this bug about?  What's anaconda doing that it shouldn't, or not doing that it should?

(In reply to comment #4)
> What exactly is this bug about?  What's anaconda doing that it shouldn't, or
> not doing that it should?

Hello, Chris,

I've opened this just to *make sure* that:

- anaconda puts the following in /etc/sysconfig/i18n if someone chooses Romanian language during install:

LANG="ro_RO.UTF-8"
SYSFONT="Lat2-Terminus16"

- the Terminus fonts are actually installed (the terminus-font-x11 and terminus-font-console packages). Please note that *any* default font is OK, *if* it contains correct comma-below characters for Romanian (*not* cedilla-below);

- anaconda puts the following in /etc/sysconfig/keyboard if someone chooses Romanian language during install:

KEYBOARDTYPE="pc"
KEYTABLE="ro"

The last line was "ro_win" in previous versions; this is now obsolete.


IMHO, these changes should be backported into RHEL as well, ASAP. This is because the usage of (incorrect) cedilla-below characters, instead of (correct) comma-below for Romanian language is a loooooongstanding bug ;-)

It seems all the necessary pieces to correct this bug (ie keyboard arrangements & fonts) are in place now; all we have to do is to make sure that we actually *use the new settings by default*.


Thanks a lot,
Razvan

> - anaconda puts the following in /etc/sysconfig/i18n if someone chooses
> Romanian language during install:
> 
> LANG="ro_RO.UTF-8"
> SYSFONT="Lat2-Terminus16"

Confirmed.

> - the Terminus fonts are actually installed (the terminus-font-x11 and
> terminus-font-console packages). Please note that *any* default font is OK,
> *if* it contains correct comma-below characters for Romanian (*not*
> cedilla-below);

Neither of these got installed.  Someone with better knowledge of the language than I needs to check that whatever fonts are getting installed work.  If not, we should file a bug against comps to make sure the right font is included in the Romanian Support group.

> - anaconda puts the following in /etc/sysconfig/keyboard if someone chooses
> Romanian language during install:
> 
> KEYBOARDTYPE="pc"
> KEYTABLE="ro"
> 
> The last line was "ro_win" in previous versions; this is now obsolete.

Whoops, we need to regenerate the keymaps-* files for this to work right.  I'll take care of that.

> IMHO, these changes should be backported into RHEL as well, ASAP. This is
> because the usage of (incorrect) cedilla-below characters, instead of (correct)
> comma-below for Romanian language is a loooooongstanding bug ;-)
> 
> It seems all the necessary pieces to correct this bug (ie keyboard arrangements
> & fonts) are in place now; all we have to do is to make sure that we actually
> *use the new settings by default*.

Hello,


Just a quick note:


I'm running rawhide now, with latest online updates (obtained by upgrading a standard Fedora 9).

I've noted that, even if select the Romanian settings (language + keyboard), these keep reverting to the English defaults on each session (at each login, be it graphical or command line).

It seems I have no mean to set Romanian as the *default* system language and keep that setting as such for all sessions, all users.

What I'm trying to set up is:

- Romanian language (in system-config-language), with correct comma-below system fonts;
- Romanian keyboard (the "Romanian" layout in system-config-keyboard).

BTW, the system-config-keyboard utility has no entry in Gnome's System -> Administration menu, at least on my system - it must be manually launched from a terminal.


Regards,
Razvan

I don't think Fedora or any other distribution has something that sets up the keymap in X. For that you have to edit xorg.conf or select the Romanian keymap in gdm (welcome screen) after selecting an user (it will remain that way next time) or use Gnome's keymap settings.

Hello, Alex & all,

Regarding comment #8 


> select the Romanian keymap
> in gdm (welcome screen) after selecting an user (it will remain that way next
> time)

No, it doesn't remain that way next time (at least on my system) when setting Romanian. That's precisely the point...  ;-)

> or use Gnome's keymap settings.

I'm interested in finding out the *canonical* way of setting keyboard layout in Red Hat-like distros, in both X mode and text mode (that's for my non-technical, completely dumb users; please don't recommend hacking xorg.conf  manually ;-)  ).

In X, this way used to be System -> Administration -> Keyboard, which mysteriously dissapeared from the menu around Fedora 8; no other obvious substitute utility was offered (at least I don't know any).

In text mode, users expect something like system-config-keyboard, an ncurses-based utility...


Best regards,
Razvan

Regarding X, the problem is that there is no tool to fully configure the xorg.conf through a more human interface.

But isn't this a system-config-keyboard bug ? including the disappearing from the Administration menu that I can confirm too.

There may be users that want the GUI in Romanian but the keyboard in english, so these settings should be kept separate; you can select them both in the install process anyway.

For me, the separate tools system-config-language and system-config-keyboard (with both graphical AND ncurses version) provide enough functionality.

I think we also struck a gdm issue here. Please look to the following image (on a system in default runlevel 5):

http://www.flickr.com/photos/afsilva/2380086988/

After the system boots (cold boot with no special user intervention), the user selected in the list is the first one. Please note that, during this time, there is *no dropdown list on the status bar* - that would allow selecting language, keyboard layout and desktop manager.

These dropdown lists on the status bar show up just *after* one selects another entry in the list (just select it, not log in).

So the first connecting user has no chance to choose the preferred language/keyboard/desktop firsthand, unless he selects the second list entry, then come back to the first. 


Should we file a bug on gdm ?


Răzvan

(In reply to comment #11)
> 
> After the system boots (cold boot with no special user intervention), the user
> selected in the list is the first one. Please note that, during this time,
> there is *no dropdown list on the status bar* - that would allow selecting
> language, keyboard layout and desktop manager.
> 

This is no issue, you don't need a particular keymap to select the user.
If you select Other user or click on an existing user and the password/user prompt appears, you then can select the keymap in case you used special characters in your password.

Regarding comment #12

Maybe so - what if the password contains, for example, language-specific characters (very improbable, but possible) ?

Apart of this, the mentioned behaviour of the gdm userlist is at least strange:

IMHO, the first connecting user must be informed (from the very beginning, without any special action required) that *he has the option* to select language, keymap and desktop manager. So those dropdown lists should be present permanently on the statusbar.

And user selection on these three items, for user X, should be „memorised” and remain the same until explicitly changed by him.

At the time being, the latter is not the case with the settings for Romanian, as I've experienced on my system.

Should we file a bug to gdm ?


Regards,
Răzvan

These all sound like valid bugs, but should be filed against the appropriate desktop components or they're going to get lost here.  I've updated the keymaps in Rawhide, so if someone knowledgable could verify that (1) the right keymap is set up by anaconda, and (2) the console/X font packages that are installed are correct it would be helpful.  Thanks.

Hello, Chris, Alex & all,


After last night online upgrades, *some* of the described behaviour seems to be corrected: when one logs in Fedora using gdm, the language/keyboard/desktop manager drop-down lists show in the status bar in *every* situation (actually, when user preses Enter and starts to insert password).

However, even if I log in with "Romanian/Romanian/GNOME" (as in last session - settings were correctly preserved this time !), I still have no correct Romanian keyboard support afterwards.

Actually, after logging in, pressing AltGr+s or AltGr+t triggers other Mozilla Thunderbird, Firefox or OpenOffice.org editor functions, instead of generating correct Romanian-specific characters on my US keyboard.

This can be corrected by manually rerunning system-config-keyboard from a terminal (as I said, there is no menu entry for it under System -> Administration...), but is extremely annoying.

To what component should I correctly file these bugs, please ?


Regards,
Razvan

These issues sound like they're related to gdm.  Reassigning.

If you already have a different layout selected in your session, the gdm selection won't override your session configuration. That is because we can't know if the user intentionally choose a different layout on the login screen, or just overlooked the combobox, causing it to carry the system default layout.

Either use the keyboard capplet (system > preferences > hardare >keyboard) to pick the correct layout in the session, once, or remove the session settings altogether (e.g. by removing ~/.gconf - but that looses all your other session settings as well, so be careful). If you do that, the gdm layout _will_ be transferred in the session the next time you log in.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Hello,


I'm able to confirm that this bug about inconsistent settings in the /etc/sysconfig tree is still present in the *official* release of Fedora 10, somewhere between preupgrade and anaconda.


Please follow the following steps to verify (I've experienced this personally on a number of machines running F9):


1. Take a pre-F10 Fedora system (stock install), in default runlevel 3;

2. Using the standard tools in Gnome's System menu, configure the keyboard for Romanian. The file /etc/sysconfig keyboard will now contain the line:

KEYTABLE="ro_win"

3. Using preupgrade-cli, ask system to upgrade to "Fedora 10 (Cambridge)"; official repositories content as in the state of November 28, 2008.

4. First stage of preupgrade will perform smoothly.

5. Reboot.

6. After reboot, preupgrade will try to start anaconda.

7. Just before the first graphics screen, upgrade will exit unexpectedly (system will offer the possibility to reboot); the presence of "ro_win" in the above line, which is now "unknown", is explicitly invoked as the reason of failure;

8. Reboot system, entering in the the old version of distro (functional).

9. Modify system's keyboard setting to "English (US)", using the standard tools in the System menu;

10. Reboot again; try to resume preupgrade.

11. Upgrade will fail again, for the same reason as in step 7.


Thanks,
Răzvan

This sounds like an anaconda issue.

This bug is all over the map though.  Please make sure to file separate issues as separate reports.

Răzvan - can you please attach the error you are seeing in comment #19, point (7)?  It's hard to tell what's going on or what needs fixing without that piece of information.  I'd also like to note that I took care of the keymap problem from way back in comment #6 as well as verified the /etc/sysconfig/keyboard setting that anaconda writes out.  If there are now additional bugs you're running into, I'd really like to close this one out and start with a new bug that describes the new issues.  Thanks.

Hello, Chris,


Let's be systematic:  ;-)

1. For issues in comment #6, they seem to be solved in Fedora 10; they are still present on all my CentOS 5.2 machines, so I've opened bug #472176 on RHEL. IMHO, this should not be treated as a RFE for RHEL 5.2, but as a fix for a bug affecting Romanian language support.

Particularily annoying is the absence of *at least one font* with correct Romanian UTF-8 characters in the *default* install of RHEL/CentOS 5.2 - such as the pair terminus-font-console/terminus-font-x11 .rpm packages. These should be automatically installed and used when Romanian language support is requested, at any time.


2. For issues in comment #19: I've hit them during upgrading some of my machines via preupgrade. Since these upgrades ended, I have to prepare a purposely crafted test machine to reproduce this - I'll do that voluntarily.

But since the crash occurs in a transitional phase, followed by a forced reboot, please let me know where exactly these events are logged (the screen output is pretty quick and I cannot copy the error message by hand or cut&paste it in a regular text file).


Thanks a lot,
Răzvan

With all the rhpl removal that we've done lately (specifically, moving keyboard selection to s-c-keyboard) and my rewrite of language.py, can you please verify if you are still seeing any issues in rawhide?

Thanks for your kind attention for this !

Unfortunately, I cannot answer this on the spot - I am running Fedora on some *production* machines and cannot afford to install rawhide when still in alpha stage.

I'll prepare a special-crafted PC, running rawhide, to verify this...

Thanks again,
Răzvan

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Putting this in need info.

Răzvan,

Can you please do a *Fresh* install of Fedora 12 in a machine and
verify that /etc/sysconfig/keyboard and /etc/sysconfig/i18n are correct, and
that the proper console font is installed ?

Thanks,

Hans

After a fresh install of Fedora 12, the content of these files is:

/etc/sysconfig/keyboard:

KEYTABLE="ro"
MODEL="pc105"
LAYOUT="ro"
KEYBOARDTYPE="pc"


/etc/sysconfig/i18n

LANG="ro_RO.UTF-8"
SYSFONT="Lat2-Terminus16"

IMHO, these entries are OK.

However, the Terminus font packages which are called in /etc/sysconfig/i18n are still not installed by default during a Romanian installation - namely, the packages:

terminus-fonts
terminus-fonts-console

IMHO, these fonts should be part, by default, of any Romanian installation.

It is possible that other font packages contain the correct glyphs (comma-bellow, not cedilla-bellow), but I don't know how to verify this.


Thanks a lot,
Răzvan

(In reply to comment #27)
> After a fresh install of Fedora 12, the content of these files is:
> 
> /etc/sysconfig/keyboard:
> 
> KEYTABLE="ro"
> MODEL="pc105"
> LAYOUT="ro"
> KEYBOARDTYPE="pc"
> 
> 
> /etc/sysconfig/i18n
> 
> LANG="ro_RO.UTF-8"
> SYSFONT="Lat2-Terminus16"
> 
> IMHO, these entries are OK.
> 
> However, the Terminus font packages which are called in /etc/sysconfig/i18n are
> still not installed by default during a Romanian installation - namely, the
> packages:
> 
> terminus-fonts
> terminus-fonts-console
> 
> IMHO, these fonts should be part, by default, of any Romanian installation.
> 
> It is possible that other font packages contain the correct glyphs
> (comma-bellow, not cedilla-bellow), but I don't know how to verify this.
> 

Thanks for the information!

One more question, if you run system-config-language and change the language
there, save, exit, and then re-run change back. Does the font named in
/etc/sysconfig/i18n change, and is the new font installed by default ?

(I'm trying to figure out if we need to write a different font by to 
 /etc/sysconfig/i18n, or if we need to get the terminus-fonts
 packages installed by default).

Also do you consider the Lat2-Terminus16 font a good choice for Romanian, or
is there another font in Fedora which would be a better choice (and maybe already gets installed by default) ?

Thanks,

Hans

Thanks a lot, Hans !


Regarding the last question - fonts:

IMHO, Lat2-Terminus16 is a good choice for Romanian, but I think ANY UTF-8 WILL DO if the following conditions are simultaneously met:

1. Contain glyphs for comma-below characters (NOT cedilla-below) - namely the following UTF-8 codes:

- 0218, not only 015E (Ș)
- 0219, not only 015F (ș)
- 021A, not only 0162 (Ț)
- 021B, not only 0163 (ț)

Cedilla-below characters are NOT CORRECT for Romanian language (it was just a historical mistake). Cedilla-below are traditionally used in Turkish...


2. Both graphical (X) AND console fonts (as in runlevel 3) are available by default.


3. The necessary fonts and keyboard maps are installed in the VERY FIRST STAGE of a Romanian Fedora installation, so no subsequent install script will produce a traceback because of these missing elements (especially when performing text installations).


The main difference between German settings and Romanian settings is that Romanian language is not fully covered by the ISO/IEC 8859‑2:1998 (Latin2) set - we need full UTF-8, mainly because the four codes given above.


Best regards,
Răzvan

Ok,

Thanks for the input, putting this back into need info until the question about what system-config-language thinks is a good console font is answered.

Also could you try changing the console font to "latarcyrheb-sun16", reboot
and see if that font has the necessary chars too ?

Regards,

Hans

latarcyrheb-sun16 does not contain ș (s with comma below), ț (t with comma below) and ”

Lat2-Terminus16 is the only font that as an extended character set afaik, I know I asked for this font to be included just because of that.

Alexandru, thanks for the information.

I just checked and anaconda automatically installs the comps group romanian-support when doing a Romanian install. So all that needs to be done is add
terminus-fonts-console as mandatory to the romanian-support group.

Changing component to comps.

I'll also file a bug for RHEL-6 to make the same change there.

Regards,

Hans

Please add TWO packages to the romanian-suport group:

terminus-fonts
ftp://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/fedora/12/Everything/x86_64/os/Packages/terminus-fonts-4.28-9.fc12.noarch.rpm

terminus-fonts-console
ftp://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/fedora/12/Everything/x86_64/os/Packages/terminus-fonts-console-4.28-9.fc12.noarch.rpm


Thanks a lot,
Răzvan

Răzvan,

terminus-fonts are old bitmap fonts for X (gnome/kde) use, why would we want those? Have you tried typing ș (s with comma below), ț (t with comma
below) in X without terminus fonts installed ?

That works fine, as I just did that when entering this comment :)

Modern X applications use pango and that is smart enough to get this characters displayed without needing those old bitmap fonts.

Regards,

Hans

terminus-console-fonts added as mandatory in Romanian support group. terminus-fonts added as optional.