Bug 1224053

We know very well that it's been a dead project for many years; but it was pretty much the only reliable way to get i18n support for the YaST NCurses UI for languages outside the Latin1 (Western Europe) and parts of the Latin2 (Eastern Europe; CZ, PL, HR) world. In particular, CN, KO, JP were problematic without it.

Dropping fbiterm would pretty certainly mean no more support for Chinese, Japanese, Korean in YaST NCurses; and I am unsure how well cyrillic locales (Russian, Ukrainian, Bulgarian etc.) or Greek would work.

> Related JIRA references: jsc#PED-3655 jsc#PED-7839

Fair enough. Do we have a Jira meanwhile deciding *pro* dropping?

Jira refernces:

https://jira.suse.com/browse/PED-3655

https://jira.suse.com/browse/PED-7839

BTW, it's not just a build dependency. YaST has also code for fbiterm wrapping.
This would also have to be removed.

A more coordinated activity would not be a bad idea, imho.

(In reply to Stefan Hundhammer from comment #3)

> https://jira.suse.com/browse/PED-7839

Let's keep the discussion in this PED I'd say... discussion seems a bit circling there.

From my PoV: I got a delreq for a package that will fail to build 'soon' (when switching compiler to gcc14); either that package gets fixed or not used anymore. Pretty much the only options.

> Let's keep the discussion in this PED I'd say... discussion seems a bit
> circling there.

That Jira is about SLE. It will never get removed from SLE15-SPX, for
maybe good reasons.

But there's a fair chance to move things forward for Tumbleweed. Just
a bit better coordinated than a pull request that will just make
installation-images builds fail.

Why will it fail?

Steffen can you please explain what has to be done to get rid of this in tumbleweed? We are running in circles on this for far too long :)

Tumbleweed (still) uses the YaST-based Installer.
YaST-based installer uses fbiterm for supporting CJK languages in ncurses.
This was implemented as requested in fate#325746.
Installation-images contain fbiterm because YaST needs it ^^^.
We plan to replace YaST-based installer with Agama. In SLFO, Leap, Tumbleweed.
Agama is not capable of all the needed features yet to replace it.
I believe, that if you wait just a little bit longer, it will just happen...

fbiterm is not needed for supporting CJK locales in ncurses. ncurses are perfectly capable of displaying CJK characters without fbiterm (under X11, over a serial port, over a SSH connection).

yast does not need fbiterm. It can run perfectly fine without it. In fact it has code to determine if fbiterm works and only runs it if it does not outright crash.

Unfortunately, fbiterm can also fail silently, and then yast runs fbiterm because it did not determine it's failing, and user is provided with a very nice blank or frozen screen.

> perfectly capable of displaying CJK characters without fbiterm (under X11, over
> a serial port, over a SSH connection)

NOT on a local text console. And that is exactly the purpose of fbiterm.

> We are running in circles on this for far too long :)

We are running in circles because nobody wants to make the decision. Look at
all these Jiras.

Make the decision, *document* it somewhere, and we can go ahead.

The decision needs to be done by PM - if they want us to keep the local console with CJK. And the decision needs to be done in Jira, not here.

No decision == status quo for SLE 15.

(In reply to Steffen Winterfeldt from comment #12)
> > We are running in circles on this for far too long :)
> 
> We are running in circles because nobody wants to make the decision. Look at
> all these Jiras.
> 

The Jiras are about SLE not Tumbleweed.

> Make the decision, *document* it somewhere, and we can go ahead.

My understanding is that we can't drop fbiterm while Tumbleweed still uses it in the installation-images. So the first step is to drop it from installation-images, then we can announce on opensuse-factory that we will drop it all-together.

So now the question is, where do you need to *document* the decission for installation-images. We have a pull-request for it [1]. Do you need an issue opened in github? I can't tell where we have to document this, you are the maintainer of the github project.

[1] https://github.com/openSUSE/installation-images/pull/708

> My understanding is that we can't drop fbiterm while Tumbleweed still uses it

Oh my; and someone said 'running in circles'...

What's needed is some decision along the lines of 'YaST does not really need this
weird language support on text consoles, let's remove the fbiterm code'.

THEN I can remove it from installation-images.

THEN you can drop it in TW.

Just because people are screaming 'let's drop glibc, it's a nightmare
to maintain' does not mean I should accept pull requests in that direction.

What's missing, for months now, is step 1.

*** Bug 1212948 has been marked as a duplicate of this bug. ***

Hi

(In reply to Steffen Winterfeldt from comment #15)
> > My understanding is that we can't drop fbiterm while Tumbleweed still uses it
> 
> Oh my; and someone said 'running in circles'...
> 
> What's needed is some decision along the lines of 'YaST does not really need
> this
> weird language support on text consoles, let's remove the fbiterm code'.

It's optional already. Yast can run without.

> 
> THEN I can remove it from installation-images.
> 
> THEN you can drop it in TW.
> 
> Just because people are screaming 'let's drop glibc, it's a nightmare
> to maintain' does not mean I should accept pull requests in that direction.
> 
> What's missing, for months now, is step 1.

Who makes this decision for TW?

If it's only about 'is this useful to anyone', did you see 

https://jira.suse.com/browse/PED-3655?focusedId=1309326&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1309326

?

Proposal to get forward with this in TW:

We could drop fbiterm in Factory / TW with the caveat that CJK languages (Chinese, Japanese, Korean) would no longer be supported for a YaST NCurses installation.


We'd still have to remove the fbiterm case in the YaST startup scripts, of course.

https://github.com/openSUSE/installation-images/pull/715

I've merged the above pull request.

The result is that YaST shows a popup 'The selected language cannot be
used in text mode. English is used instead...' if you start with Chinese,
for example.

I suppose it could expand on that pointing out that the language is available when installing using X11, over serial console or over ssh. With the caveat that the locale needs to be available for yast, not sure if/how that is taken into account when trying to switch console locale.

This is a temporary solution before we switch to Agama. Ne additional features to be implemented.

On Mon, May 13, 2024 at 06:11:39PM +0200, Michal Suchánek wrote:
> On Mon, May 13, 2024 at 04:22:38PM +0200, Michal Kubecek wrote:
>> On Mon, May 13, 2024 at 12:56:22PM +0200, kbuild@suse.de wrote:
>>>
>>> commit 59423a933cb917b60a84fa090a2804997c95e450
>>> Author: Michal Suchanek <msuchanek@suse.de>
>>> Date:   Mon May 13 12:36:30 2024 +0200
>>>
>>>     Update config files (boo#1224053).
>>>     
>>>     DRM_FBDEV_EMULATION=n
>>
>> I went through bsc#1224053 but I don't understand how is this config
>> change related to it. The bug is about dropping a userspace package and
>> does not mention kernel configuration at all. Is fbiterm known to be the
>> only possible use case for CONFIG_DRM_FBDEV_EMULATION or how is this
>> pull request related?
>
> Yes, we are keeping fbdev emulation enabled for fbiterm, there is no
> other use expected.
>
> There are possibly some drivers for small SPI and i2c displays that do
> not support DRM but for devices that do the fbdev emulation is
> superfluous with fbiterm gone.


Me as well confused. Pasting the explanation ^^^

(In reply to Jiri Slaby from comment #23)
> On Mon, May 13, 2024 at 06:11:39PM +0200, Michal Suchánek wrote:
> > On Mon, May 13, 2024 at 04:22:38PM +0200, Michal Kubecek wrote:
> >> On Mon, May 13, 2024 at 12:56:22PM +0200, kbuild@suse.de wrote:
> >>>
> >>> commit 59423a933cb917b60a84fa090a2804997c95e450
> >>> Author: Michal Suchanek <msuchanek@suse.de>
> >>> Date:   Mon May 13 12:36:30 2024 +0200
> >>>
> >>>     Update config files (boo#1224053).
> >>>     
> >>>     DRM_FBDEV_EMULATION=n
> >>
> >> I went through bsc#1224053 but I don't understand how is this config
> >> change related to it. The bug is about dropping a userspace package and
> >> does not mention kernel configuration at all. Is fbiterm known to be the
> >> only possible use case for CONFIG_DRM_FBDEV_EMULATION or how is this
> >> pull request related?
> >
> > Yes, we are keeping fbdev emulation enabled for fbiterm, there is no
> > other use expected.
> >
> > There are possibly some drivers for small SPI and i2c displays that do
> > not support DRM but for devices that do the fbdev emulation is
> > superfluous with fbiterm gone.
> 
> 
> Me as well confused. Pasting the explanation ^^^

https://kerncvs.suse.de/gitweb/?p=kernel-source.git;a=commit;h=59423a933cb917b60a84fa090a2804997c95e450

Michal, please revert this patch. You've just disabled the kernel console entirely.

What you want is CONFIG_FB_DEVICE=n, which disables only the fbdev userspace interfaces (/dev/fb*). It's also unrelated to the bug here. You can log that change against bsc#1212947.

(In reply to Thomas Zimmermann from comment #24)
> https://kerncvs.suse.de/gitweb/?p=kernel-source.git;a=commit;
> h=59423a933cb917b60a84fa090a2804997c95e450
> 
> Michal, please revert this patch. You've just disabled the kernel console
> entirely.

Now pushed to users/jslaby/master/for-next

Merged now.

Sorry for this. I was a bit worried that there was no mention of the
CONFIG_DRM_FBDEV_EMULATION kernel config option in this bug so I asked
Michal Suchánek how is it related and if fbiterm is known to be the only
known use case for it. Should have asked someone responsible for the
subsystem instead.

Draft PR for the YaST side:

  https://github.com/yast/yast-installation/pull/1117

(not strictly needed, this is more a code cleanup; YaST would always fall back to not using fbiterm if it isn't available)

(In reply to Michal Suchanek from comment #21)
> I suppose it could expand on that pointing out that the language is
> available when installing using X11, over serial console or over ssh. With
> the caveat that the locale needs to be available for yast, not sure if/how
> that is taken into account when trying to switch console locale.

(In reply to Lukas Ocilka from comment #22)
> This is a temporary solution before we switch to Agama. Ne additional
> features to be implemented.

This is not about implementing additional feature.

This is about fixing the message

log "\tLanguage $LANG is unsupported in NCurses, falling back to en_US.UTF-8"

added in

>   https://github.com/yast/yast-installation/pull/1117

to reflect reality.

That is ncurses can support most languages perfectly fine. The Linux console cannot. Which means that using the ncurses installer with ssh or serial connection the locales can be supported, and that's something the message could mention as well.

Before you are spreading more FUD, please check WHEN this message appears: It's only on the system console, and only if the terminal type is "linux".

Yes, I am aware of that.

It does not make what the message says any more true.

That is 

"Language $LANG is unsupported in NCurses, falling back to en_US.UTF-8"

is false. ncurses does support most loanguages.

Whereas

"Language $LANG is not supported on the Linux text console, falling back to en_US.UTF-8\nMore languages are available in graphical installers and when installing using SSH or serial console."

is both true and provides useful information.

This is the message that goes to y2start.log. It's meant to be concise, not an encyclopedia article. And the target audience is YaST developers working on bug reports and advanced users who are actually looking into log files.

SR to OBS:

  https://build.opensuse.org/request/show/1177300

This will become available with yast2-installation-5.0.11.

(Factory / Tumbleweed only, no SLE-15-SPx / SLE-12-SPx).