[karmic] Regression from 9.04 in getting fully translated Ubuntu installation

I'm currently working on a command line tool to be run by other applications, which returns the list of missing packages based on a given language code or all languages which are already installed as language-packs on the system.

The original plan was to change the packages, like openoffice.org-core and others to run this script during postinst and display the notification message when something is returned. The user will still need to launch language-selector to install the missing packages.

I hope, that for 10.04 we can integrate this functionality into the installer and update-manager (at least) directly, so that they can dynamically adjust the dependencies during evaluation what to install.
As you know already, this only works if an Internet connection is available. That would need to be solved, too...
I guess this is something for UDS Lucid.

in my branch: lp:~arnegoetje/language-selector/language-selector-karmic

Let's just integrate this into the installer for 9.10 - it's a regression fix. I don't know about update-manager - it would be a good idea to grab Michael Vogt and ask him about this if you haven't already.

I'm a little concerned about displaying a notification in postinsts as it seems that it would require some care to avoid continually spamming people with notifications in the event that they've explicitly decided not to install some particular piece of language support.

Note that there is a related bug for upgrades: bug 439296

"Installer would co-operate with language-selector to install everything during installation time, if Internet connection happens to be enabled (something like language-selector --fix-missing)"

I think it will be better if we can select which software source the installer will use.

You see, there are many Chinese user complain that their installations freeze at approximate 70% unless they unplug their internet wires. These users have working internet connections, but the download speed is too slow that the whole download job will not finish in hours since they can't decide where to download.

So, i think if you guys are working on this stuff, why not let users decide which software source they want to use.

Note that fixing this will affect bug 437368.

Jimhu: please don't jump into entirely unrelated bug reports with problems. This really has nothing to do with this bug, which is strictly about which packages are selected for installation, not where those packages are acquired from.

Hi, in ubuntu 9.10 beta1, installation in french, i have some translation problems.
See attachement (english messages does not have to appear).

This bug was fixed in the package pkgsel - 0.25ubuntu3

---------------
pkgsel (0.25ubuntu3) karmic; urgency=low

  * Use check-language-support if available to select language support
    packages (LP: #434173).

 -- Colin Watson <email address hidden> Wed, 14 Oct 2009 22:38:12 +0100

This bug was fixed in the package ubiquity - 2.0.0

---------------
ubiquity (2.0.0) karmic; urgency=low

  [ Colin Watson ]
  * Bump to a stable version number series for Ubuntu 9.10.

    The main reason for the version bump was because we incorporated
    oem-config and needed to jump past its version numbers, but really
    Ubiquity 2.0.0 is quite different from Ubiquity 1.0.0 despite most of
    the changes being gradual and incremental. 3.5 years and nearly 5000
    lines of changelog entries later, we have several active developers,
    lots more translations, apport integration, a new partitioner,
    migration-assistant, automation, Mythbuntu and noninteractive frontends,
    Wubi, reinstallation without reformatting, a new timezone map,
    accessibility, many UI improvements, a slideshow, plugin support, and
    much more. Here's to version 3!

  * Install kernel headers to match the kernel (LP: #413135).
  * Recommend dmraid to ensure consistent behaviour across Ubuntu flavours
    (it was already present on the Ubuntu desktop CD, but e.g. not on
    Kubuntu).
  * If dmraid devices are active, then create
    /var/lib/disk-detect/activate_dmraid so that partman will exclude slave
    devices, and ensure that dmraid is installed in the target (LP: #90235).
  * Use check-language-support if available to select language support
    packages (LP: #434173).
  * Update translations from Launchpad.
  * Automatic update of included source packages: base-installer
    1.102ubuntu2, hw-detect 1.72ubuntu5.

  [ Jonathan Riddell ]
  * ubi-intro.py: detect kubuntu-netbook-intro.txt if it exists and use
    that as warning for Kubuntu Netbook Edition

 -- Colin Watson <email address hidden> Wed, 14 Oct 2009 23:57:40 +0100

Michael, is there anything we can do about the update-manager element of this for 9.10, or possibly in an SRU?

I'm not entirely sure what the best course of action is here for update-manager in the release-upgrade context.

When update-manager runs on jaunty it will not have check-language-support available. So it either needs to embed a copy of it or run it after the upgrade has finished. This would add additional step (something I dislike) or make it part of the cleanup process (where it does not belong).

Additionally in the context of upgrades we do not want to add stuff during the upgrade that the user may have refused explicitely (e.g. because the download size for some of the help files is too big or because he does not need it). That means that u-m needs to run a "check-language-support" before the upgrade to see what is missing now and after the upgrade to see whats missing then and just install the new dependencies. If the list of the new/changed dependencies is small, we could ship that instead of a a full copy of the check-language-support code.

I just looked at the code and it seems like the release-upgrader needs to know what the "pkg_depends" file would look like on jaunty (there it does not exist and its done via metapackages). With that it could do the compare relatively easily.

Hm, and the code in l-s that deal with zh_* via code. But if that is no change compared to the jaunty state it could stay.

I just talked to Arne about it and there are a couple of issues here:

1. langauge-support-extra-$lang is gone, so we either need to transition its dependencies form automatic to manual or ignore that and they will be removed as no-longer-used-automatic-dependencies
2. language-support-translations is gone too, but the dependencies are set to manual on upgrade via a quirks handler
3. the previous dependencies of language-support-translations are now managed via pkg_depends and u-m should be deal with them as if it was a meta-package with recommends. i.e.
 a) install them as manual dependencies
 b) only install new ones (and not re-add previously deselected)
 c) do not fail if they can not be installed

Attached are the pkg-depends from Jaunty for the language-support-translation metapackages.

The zh- metapackages have been split into zh-hans (Simplified Chinese) and zh-hant (Traditional Chinese). The zh metapackages now depend on the zh-hans and zh-hant metapackages and are only needed for upgrading.

A alternative solution is to just make update-manager check the situation on upgrade and drop a upgrade note that will appear on first boot if some language-support is incomplete. This has the advantage that the user will have fine control via language-selector and that check-language-support is available and there is no need to embed it. It also means that its generic enough to work for hardy->lucid next cycle too.

Hi Timo,

I believe this bug has now been fixed.

I understand that the expected behaviour you are mentioning in a), where the installer and language-selector cooperate to install all language-dependant packages has been implemented. As per b), I'm not quite sure I can follow it, so if this is not yet implemented as you were describing it, may I ask you to expand a bit on that?

Other issues mentioned in the report are being handled separately as bug 527623 and bug 441321.

If you believe there are still remaining bits, please feel free to reopen.

Thanks!

It's indeed fixed as far as the regression is concerned.

The b) part is that full language support should be downloaded automatically after the installation similarly to automatic downloading of language support during installation, if network connection is available. Currently it is suggested by a dialog the user might see, but I do think that the full (selected) translation support should be installed as automatically as possible once in the case of a fresh install, whether it is during the installation or after the installation. Therefore the update-manager was a logical place to consider a hook - if updates are being downloaded, the first batch of updates could also include whatever is missing from the language support that was selected in the installation.

El dc 07 de 04 de 2010 a les 10:06 +0000, en/na Timo Jyrinki va
escriure:
> It's indeed fixed as far as the regression is concerned.
>
> The b) part is that full language support should be downloaded
> automatically after the installation similarly to automatic downloading
> of language support during installation, if network connection is
> available. Currently it is suggested by a dialog the user might see, but
> I do think that the full (selected) translation support should be
> installed as automatically as possible once in the case of a fresh
> install, whether it is during the installation or after the
> installation. Therefore the update-manager was a logical place to
> consider a hook - if updates are being downloaded, the first batch of
> updates could also include whatever is missing from the language support
> that was selected in the installation.
>

Ah, I get you now, thanks for the clarification.

I think these are separate issues, so do you think you could file a
separate bug for your enhancement proposal? I'd suggest filing it
against update-manager and perhaps opening tasks for language-selector
and ubuntu-translations.

Please do not reopen this bug. If you have an issue with getting a fully translated Ubuntu install, open a new bug.

anything left to be done in this ticket for update-manager? It seems to be specifically aimed at karmic which is EOL.

Regarding the original description everything and more has been done in language-selector, update-manager and ubiquity. There could be some more ideas for enhancement, but they are worth new bugs.