I am trying to use debconf to preseed the values for the locales package in Debian squeeze, so that I can reconfigure it non-interactively to, e.g., generate all locales. I extract the right selection from a working system using debconf-get-selections, and then feed them to debconf-set-selections on the new system.

It is working for other packages, e.g. sun-java6-bin, not quite for locales. I am able to set the values with debconf-set-selections, but if I reconfigure locales with dpkg-reconfigure (or reinstall it with, e.g., apt-get install --reinstall locales, for that matter), the values are reset and the new locales are not generated.

Symptoms are exactly the same as in debian bug #592216, but that bug is officially resolved in version 2.9-13 of the package. Squeeze has 2.11.3-4, so either the bug is still there, or I am doing something wrong.

Has anyone experienced the same thing?

Thanks in advance

-- M


Yes, I have experienced the same problem, and after fighting it for a while, I found a workaround that uses /etc/locale.gen.

I published a puppet module to configure the locales we usually use on our servers, that is, only en_US.UTF-8:


Here it is, inlined:

class locales {

  package { "locales": 
    ensure => "latest",

  file { "/etc/locale.gen":
    source => [
    owner => "root",
    group => "root",
    mode => 644,
    require => Package["locales"],

  exec { "/usr/sbin/locale-gen":
    subscribe => File["/etc/locale.gen"],
    refreshonly => true,
    require => [ Package["locales"], File["/etc/locale.gen"] ]


Even if you don't use puppet ;-), you can easily understand what's happening. You just create the /etc/locale.gen file with the list of locales you want to generate, and then run the /usr/sbin/locale-gen.

Here's the list file I use as /etc/locale.gen:

# This file lists locales that you wish to have built. You can find a list
# of valid supported locales at /usr/share/i18n/SUPPORTED, and you can add
# user defined locales to /usr/local/share/i18n/SUPPORTED. If you change
# this file, you need to rerun locale-gen.

en_US.UTF-8 UTF-8
  • Thanks cosimo, see my answer below (cfengine code included ;) – bronto Jan 9 '13 at 11:55

I managed to create a cfengine3 policy similar to @cosimo's manifest, and it appears to work. I am fine with that, but I still believe that bug #592216 is not resolved yet so I may file another one to Debian.

My cfengine implementation takes advantage of the fact that /etc/locale.gen seems to contain all the possible locales, but commented out.

Rather than rewriting the file from scratch, and possibly introduce errors, I am asking cfengine to uncomment the locales I want to be generated. If the locale is not there, be it because it's not supported or I misspelled it, nothing happens. This approach also simplifies things in that it is not necessary to write both the locale and the charset: you can just write the locale and let cfengine uncomment all the related charsets for that locale.

'nuff said:

body common control
      inputs => { "cfengine_stdlib.cf" } ;
      bundlesequence => {"test"} ;

bundle agent test
    slist => { "da_DK.UTF-8", "de_DE.UTF-8", "en_US.UTF-8",
           "es_ES.UTF-8", "fr_FR.UTF-8", "it_IT.UTF-8",
           "nl_NL.UTF-8", "ru_RU.UTF-8", "sv_SE.UTF-8",
           "tr_TR.UTF-8", "id_ID.UTF-8", "nb_NO.UTF-8",
           "pl_PL.UTF-8", "vi_VN.TCVN"  },
    comment => "locales to generate" ;

    edit_line => enable_locales(@(test.locales)),
    classes   => if_repaired("regenerate_locales"),
    comment   => "Enable locales, trigger locale-gen if needed" ;

    comment => "Regenerate locales when needed" ;

      "Locales regenerated" ;

bundle edit_line enable_locales(locales)
    replace_with => uncomment ;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.