Bug 162064

thanks for reporting, the problem is known

*** This bug has been marked as a duplicate of 156045 ***

If the KhmerOS-font package is already on CD1, it is *not*
a duplicate of bug #156045.

yes. It is another problem.

Jiri: Can you help here, please?

I just tested beta9 and the bug is present there as well. 

After talking to Chumsoben it appears that we have different bugs. 

His problem in Beta8 was that after restart he got another Khmer font and not KhmerOS System. This is something I understand somehow. I think that Yast is not selecting any font at all and depends on the font substitution feature of QT in order to find a Khmer font for the text. The install system from CD 1 has only one font but after the switch to the installed system there are more fonts available and QT (or any other underlying code) picks just the first Khmer font it can get. The only solution I see here is to tell QT somehow that KhmerOS System is a preferred font for Khmer.

My problem in Beta9 was that I do not get any Khmer at all, only boxes. I tried this in vmware and I will try again in a normal installation in order to see if I can reproduce this. 

In Beta9 I still get the same problem as Beta8.

I have no clue about those exotic fonts.

Mike?

Nico is currently burning me a set of CDs for RC1, I'll test this
as soon as I have the CDs.

When installing RC1 from a CD-set in Khmer language, I can confirm that
boxes are shown after the initial reboot (after CD1 is finished).

The package KhmerOS-fonts-3.1-9.noarch.rpm is on CD1 of RC1, i.e. the problem
is not caused by a missing package on CD1.

But the package has not been installed, although KhmerOS-fonts.spec contains the line

    Provides:       locale(km)

which should cause the package to be installed if Khmer language is selected
as primary or secondary language.

I talked with Stefan Hundhammer and we experimented a bit.

When selecting Khmer as an additional language in YaST2 in an already
installed system, the KhmerOS-fonts package was selected.

But chen clicking on the [check] button (which runs the solver),
the package was deselected again.

→ seems to be a bug in the solver.

Stefan then tried the same procedure again with a somewhat newer SuSE 10.1 installation
tree (i.e. post RC1) and could not reproduce the problem again.

I.e. this problem *might* be already solved, but we are not sure.

→ reassign to Klaus Kämpf <kkaempf@novell.com> because it is a solver problem.

The same problem occurs for Japanese, although the package
"sazanami-fonts" is available on CD1, it is not installed
after the initial reboot.

→ Blocker, because this problem seems to occur for all languages not
covered by the DejaVu fonts (Hebrew, Punjabi, Chinese, Korean, Japanese, Khmer, ...)

comment #14, need logs

Happens for simplified Chinese as well. ttf-arphic-gbsn00lp is on CD1
but is not installed after the initial reboot.

I cannot supply the logs for comment #14 because this was done
on Stefan Hundhammers machine. Maybe Stefan can supply logs.

I'll try to attach logs for the problems mentioned in comment #16,
comment #19, and comment #12. These problems are 100% reproducible
with RC1.

For some of the languages (e.g. Punjabi) I can reproduce it on my machine with STABLE-i386 as the inst-source. For others that showed the problem yesterday I cannot. Do the packages still change that heavily?!

Created attachment 79288 [details]
yast-logs.tar.bz2

tar ball of /var/log/YaST2 after the initial reboot.

Installation has been started in simplified Chinese.

Created attachment 79449 [details]
y2log.tar.bz2 

Lars Rupp and me tested again Build 1005 with Khmer.

YaST log attached.

After the initial reboot, boxes where shown, the Khmer font package
was not installed although it was available on CD1.

We installed it manually and rebooted, then Khmer displayed correctly.

y2log shows that the "km_KH" language was never selected.

U__s_[language]km_KH-.noarch

So YaST fails to actually pass the language information to zypp. -> visnov

Mike, where did you select the language ? In the initial language selection (as primary language) or in the detailed package selection (as secondary language) ?

comment #24: to be precise: y2log from comment #23

logs from comment #22 also show km_KH as not selected.

Klaus> Mike, where did you select the language ? In the initial
Klaus> language selection (as primary language) or in the detailed
Klaus> package selection (as secondary language) ?

In the initial language selection in Linuxrc (that is the primary
language of course).

Klaus> logs from comment #22 also show km_KH as not selected.

The logs attached in comment #22 are for simplified Chinese, not Khmer.

Selected in Linuxrc. The same problem occured, the simplified Chinese font package
ttf-arphic-gbsn00lp was not installed although it was available on CD1.

I can confirm this with a German installation on RC2.  The language dependend packages are not selected in the packager.

I just tested RC2 and when I select Khmer at the _bootscreen_ and do a standard installation I _get_ the Khmer font after the reboot!

So maybe this problem also depends on where you select the language?

I remember that the same procedure worked on RC1 too.

HOw to reproduce:
* Boot from media
* first screen: Choose German
* Do new installation
* Enter package manager
* Switch to Languages view
* NOtice that de is *not* enabled
* Notice that the only yast2-trans-de is selected but neither of aspell-de, ispelle-german, OpenOffice_org-de etc.

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

> NOtice that de is *not* enabled

You probably mean it is not enabled in the list of secondary langauges, right? This is correct.

This is not the list of secondary languages.  I clicked on the package manager not on the language manager.

Looks like a change of semantics of libzypp vs. the old package manager :(

Ladislav, is it possible to change the meaning of SetLocale back, so that it also adapts the package selection?

Yes, I'm working on that...

Fixed in yast2-pkg-bindings-2.13.65

I had to slightly modify additional locales handling, please test it in the next build too.

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

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

Jens> I just tested RC2 and when I select Khmer at the _bootscreen_ and do a standard
Jens> installation I _get_ the Khmer font after the reboot!

Jens> So maybe this problem also depends on where you select the language?

Maybe, but I also selected it in the _bootscreen_ and it did *not* work.

Jens> I remember that the same procedure worked on RC1 too.

And it didn't work in RC2 either.

Klaus Kämpf just told me that it is fixed in build 1007 (post RC2).

I'll check that now.

We've also tested it here with build 1008 and it did work (with czech, the czech-related packages were installed).

    No, it does not work with build 1009!
    
    I booted with a RC1 CD (old, but this shouldn't matter)
    and then installed from machcd2:/machcd2/CDs/SUSE-Linux-10.1-Build_1009-x86_64/CD1
    via ftp.
    
    After CD1 was finished, the Khmer font package was not installed and
    of course I saw only boxes instead of Khmer because of this.
    
    The yast2-trans-km has been installed but kde3-i18n-km has not been installed
    although I selected KDE in one of the first installation screens.
    
    → REOPEN.

Logs, please.

Created attachment 79995 [details]
yast-package-manager-khmer.png

Another weird effect:

After the installation completed, I started YaST2 ? Software Management ??Filter: Languages

Then, when selecting Khmer, no packages at all are listed on the right side.

See attached screen shot.

Created attachment 79996 [details]
yast2-logs.tar.bz2

tarball with YaST2 logs for comment #43 and comment #45.

Logs have been attached → change status to ASSIGNED again.

To make sure I retested with Japanese. The same problem occurs:

Although the package "sazanami-fonts" is available on CD1, it is not installed.

Mike, where did you select the language?

It worked for me with german if I selected at the first YaST screen.

Several notes:

1) setRequestedLocale operates on the pool, meaning it can work  only if we have all resolvables created. Jiris, please, make sure it is so.

2) YaST passes ja_JP to ZYPP. Might this be the problem? Needinfo for Michael.

3) For some languages, if I select e.g. sk_SK, it will automatically select sk. But not for all. I don't understand this at all.

Andreas Jaeger> Mike, where did you select the language?

In the linuxrc bootscreen.

Please try again. Choose the language in the first YaST screen this time.

Tested on installed system: Pkg::SetLocale ("cs_CZ") selects correctly appropriate packages. 
During the installation, the packages are not selected (however the group cs_CZ in Languages filter of package selector appears).

Ad comment #52: both situations should be the same, Pkg::SetLocale is called at the same place (Packages.ycp, l.538 inst_language client is not involved).

So the solver behaves correctly.

Could it be that Pkg::SetLocale() is called too early, before the respective language resolvable is created in the pool ?

Yes, looks like it is called before creating the source... (/me is investigating & testing ...)

Created attachment 80146 [details]
y2log gzipped

I've tried to move the call of SetAdditionalLocales in Packages.ycp further, after the creation of sources - didn't work :-(

The sequence of Pkg builtins was (after this change):

InstSysMode
SourceStartCache
SourceSetRamCache
ImportGPGKey
SourceCreateBase
SourceProductData
SourceProvideDir
SourceProvideOptionalFile
SetAdditionalLocales
ResolvableProperties
ResolvableInstall
...

Created attachment 80225 [details]
patch for /usr/share/YaST2/modules/Packages.ycp

There are 2 changes in this patch for Packages.ycp:

1. moving SetAdditionalLocales after creating the source (already mentioned in comment #56)

2. init_called = false;
before new call of Packages::Init (true) in installation proposal. The problem is that Init ignores the force parameter, so the package selection remains reset after previous call of Packages::Reset. The change of behaviour was probably caused by new (and correct) implementation of Pkg::PkgReset builtin.

Jiri, I give this for you as the solution (especially 2nd point) is more a hack than a fix and might break something else if submited.

Another issue remains: as Packages.ycp use Pkg::SetAdditionalLocales for selection of packages even for primary language, it is not necessary to alter the selection in Pkg::SetLocale, as implemented in yast2-pkg-bindings-2.13.65 (comment #38). Question is, what should be correct behaviour of Pkg::SetLocale.

Modified patch above has just been submitted to STABLE.

Still not fixed in RC3.

Created attachment 80622 [details]
YaST2/ log files

As AJ said, here are the log files. aspell-de, kde3-i18n-de, susehelp_de and koffice-i18n-de were skipped during installation and only added when running an online update.

Created attachment 80623 [details]
logfiles

I have a german installation but no german openoffice.  Didn't check the rest.

According to the log, locales are set after the last reset of packagemanager.

2006-04-27 19:13:01 <1> 10.10.0.53(3597) [wfm] Packages.ycp:96 Pkg Builtin called: PkgReset
2006-04-27 19:13:01 <1> 10.10.0.53(3597) [wfm] Packages.ycp:838 Pkg Builtin called: SetAdditionalLocales

(the lines are from the first log, the second log contains them as well).

Lado, looks like a problem in the Pkg builtin or somewhere lower. Or is there something else that has to be called?

Maybe, can the problem be that between Pkg::PkgReset and Pkg::SetAdditionalLocales other Pkg builtins are called? If so, then moving Pkg::SetAdditionalLocales to Packages::Reset just after Pkg::PkgReset would help, but I don't know, when I tested the patch, I got czech packages installed...

I see de_DE marked for transaction, but no de - the log says it cannot soft-transact it.

Anyway, solver issue. Schubi, please, take a look.

Yes, indeed:
2006-04-27 19:30:30 <0> 10.10.100.15(3307) [solver] QueueItemRequire.cc(process):809 Can't soft-transact U__u_[language]de-.noarch

It seems that the "reset" reset the language resolvables as user( U__u_). The solver has no change to set "de" through the requirement of "de_DE" again cause he cannot overwrite the user decision.

Hmm, if 'de' cant be transacted, the same error should show up for 'de_DE' ?!

But de_DE is set to be transacted by YaST and
ZYppImpl::setRequestedLocales uses User for this.

I think the fix is to not use PkgReset, but behavior like PkgNeutral.

This happens only if you enter the partitioner!  IF you do not enter it, it looks fine!

Please do a grep in YaST to check all places that call the resolver - that they initialize it correctly language wise!

Klaus has found the bug and Ladislav will take care about it.
Thanks !!!

That's not the problem - I have created a separate bug report (#170643) for the wrong reset calls.

I has fixed and submitted.
It will be checked by stano and lslezak

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