Preseeding pkgsel/language-packs is not keeping language packages installed

Bug #458333 reported by Mario Limonciello
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OEM Priority Project
Fix Released
High
Canonical Ubuntu QA Team
ubiquity (Ubuntu)
Fix Released
High
Unassigned
Karmic
Fix Released
High
Unassigned

Bug Description

Binary package hint: ubiquity

During karmic, bug 371470 was created to assist with providing a method to keep all language packages installed. It broke part way through the cycle and was fixed, but appears to have broken again.

ProblemType: Bug
Architecture: i386
Date: Thu Oct 22 06:52:49 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate i386 (20091020)
NonfreeKernelModules: wl nvidia
Package: ubiquity 2.0.2
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: ubiquity
Uname: Linux 2.6.31-14-generic i686
XsessionErrors:
 (gnome-settings-daemon:13210): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:13210): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:13330): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:13311): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed

Revision history for this message
Mario Limonciello (superm1) wrote :
Revision history for this message
Jerone Young (jerone) wrote :

Been reported this bug is more then just this language feature. But apparently will still remove languages even if they are explicitly listed.

Revision history for this message
Mario Limonciello (superm1) wrote :

When adding
  d-i pkgsel/language-packs string aa af am an ar as ast az be ber bg bn bo br bs ca crh cs csb cy da de dv dz el en eo es et eu fa fi fil fo fr fur fy ga gd gl gu ha he hi hne hr hsb ht hu hy ia id ig is it ja ka kk km kn ko ks ku kw ky la lg li lo lt lv mai mg mi mk ml mn mr ms mt nan nb nds ne nl nn nr nso oc om or pa pap pl pt ro ru rw sa sc sd se shs si sk sl so sq sr ss st sv ta te tg th ti tk tl tn tr ts tt ug uk ur uz ve vi wa wo xh yi yo zh zu

instead of
 d-i pkgsel/language-packs string ALL

The resultant system is still having all language support removed.

Brent Fox (brent-s-fox)
Changed in oem-priority:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Colin Watson (cjwatson) wrote :

Would it be possible to get a syslog from *before* oem-config was run? It looks like the act of running oem-config overwrote /var/log/installer/syslog (I'll fix that ...).

Changed in ubiquity (Ubuntu Karmic):
importance: Undecided → High
status: New → Triaged
milestone: none → ubuntu-9.10
Revision history for this message
Colin Watson (cjwatson) wrote :

Actually, /var/log/installer/syslog should be fine, it's just that the apport hook uses /var/log/syslog. Could you attach /var/log/installer/syslog from an affected system, then?

Revision history for this message
Colin Watson (cjwatson) wrote :

Or indeed, looking at it - this sounds *awfully* like a bug I fixed in ubiquity 2.0.3.

  * Use new check-language-support --show-installed option added in
    language-selector 0.4.16, so that we can arrange to keep language
    support packages installed that are already present in the live
    filesystem.

Would a quick retest with an upgraded live image be possible?

summary: - Preseeding " d-i pkgsel/language-packs string ALL" is not keeping all
- language packages installed
+ Preseeding pkgsel/language-packs is not keeping language packages
+ installed
Revision history for this message
Mario Limonciello (superm1) wrote :

The latest DVD available at http://cdimages.ubuntu.com/dvd/ is 2009-10-20, which is the same as the RC DVD this was tested with.

Consequently, I tested with a hand-downloaded Ubiquity 2.0.3 installed while booted into the livefs.
It looks like language-support-LANG is still not being kept, AND the installation process is taking much much longer.

I looked, and I think this tool check-language-support is not reporting language-support-LANG even though it's installed.

Given this, I think the attached diff will resolve both issues.

Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 458333] Re: Preseeding pkgsel/language-packs is not keeping language packages installed

I've been told that language-support-* is no longer necessary. I'm happy
to apply that part of the diff as a temporary measure for 9.10, but it
needs to be revisited later.

I arranged for check-language-support -a to work. I'll use that.
Avoiding check-language-support altogether is bad - it means that all
language support packages will be installed regardless of whether the
underlying applications are installed. This was the case pre-9.10, but
one of the goals of check-language-support was to eliminate that
brokenness.

Revision history for this message
Colin Watson (cjwatson) wrote :

Actually, thinking about it further, I'm not happy with installing
language-support-* regardless. It's possible that that will cause
support to be installed for applications that are not installed, using
unnecessary space. check-language-support is supposed to be intelligent
enough not to need the top-level metapackage.

Could you please clarify whether you have some particular reason to need
language-support-* (in addition to the other things
check-language-support lists), or is it just a case of a checklist
needing to be updated for the new world order?

Revision history for this message
Mario Limonciello (superm1) wrote :

@Post 8:
The avoidance of the check-language-support call against each language is in favor of avoiding unneededingly running the script over and over if the intention is to just keep all language support and speed the process up. For something that is just building a bunch of lists, it adds a considerable amount of runtime if you are keeping each language.

@Post 9:
There is no hard reason that language-support-* needs to be kept except that it is extra time spent spent removing package from the apt database and calculating the blacklist. If these metapackages are serving no purpose, the DVD probably shouldn't be including them in the first place. So yes, it does sound like it's something that has to be updated to the new way of doing things.

@General:
By no means does my diff have to be the solution here, i'm just trying to ensure that extra time is not introduced to that of an installation unnecessarily when the intent is to keep what was on the livefs already in favor of time.

Revision history for this message
Colin Watson (cjwatson) wrote :

On Fri, Oct 23, 2009 at 09:20:27PM -0000, Mario Limonciello wrote:
> @Post 8:
> The avoidance of the check-language-support call against each language
> is in favor of avoiding unneededingly running the script over and over
> if the intention is to just keep all language support and speed the
> process up. For something that is just building a bunch of lists, it
> adds a considerable amount of runtime if you are keeping each
> language.

I certainly agree with that, and I just committed a different approach.
'check-language-support -a --show-installed' is about as fast as calling
check-language-support for a single language.

> @Post 9:
> There is no hard reason that language-support-* needs to be kept
> except that it is extra time spent spent removing package from the apt
> database and calculating the blacklist. If these metapackages are
> serving no purpose, the DVD probably shouldn't be including them in
> the first place. So yes, it does sound like it's something that has
> to be updated to the new way of doing things.

While I agree that the DVD's seeds need to be updated, that's kind of
tricky as seeding language-support-* is the only way to get all language
support packages onto the image right now. I asked at UDS for there to
be some metadata in the Packages file that germinate could use for this,
but this never happened.

In the meantime, perhaps the best approach would be to keep
language-support-* if it's installed, but don't bother installing it if
it isn't. I'm testing a patch for that now.

Colin Watson (cjwatson)
Changed in ubiquity (Ubuntu Karmic):
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.0.4

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

  [ Evan Dandrea ]
  * Do not install the live CD kernel in the target system when using
    PAE (LP: #413135).
  * Properly set the kernel version in the main install process when
    using PAE so that symlinks get created for the kernel and initramfs.
  * Automatic update of included source packages: partman-base
    133ubuntu4.
  * Automatic update of included source packages: grub-installer
    1.43ubuntu8, partman-basicmethods 43ubuntu1.

  [ Colin Watson ]
  * Change apport hook to prefer syslog, partman, and casper.log from
    /var/log/installer/ if they exist there, to support bug-filing after
    installation.
  * Don't set the "incomplete language support" note if only gimp-help-* is
    missing, since it's far too big to fit on CDs (LP: #452516).
  * Furthermore, always consider English as "complete enough". The packages
    that are missing from an installation from the Ubuntu desktop CD are not
    critical for a reasonable user experience.
  * Make use of check-language-support -a if pkgsel/language-packs is ALL,
    since that's orders of magnitude faster (LP: #458333).
  * Keep language-support-$LL installed if it happens to be in the live
    filesystem, since there's no point spending time removing it; but don't
    install it if it isn't in the live filesystem (LP: #458333).

 -- Evan Dandrea <email address hidden> Sat, 24 Oct 2009 14:55:26 +0100

Changed in ubiquity (Ubuntu Karmic):
status: Fix Committed → Fix Released
Changed in oem-priority:
assignee: nobody → Canonical Ubuntu QA Team (canonical-qa)
Jerone Young (jerone)
Changed in oem-priority:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Patches

Remote bug watches

Bug watches keep track of this bug in other bug trackers.