plans concerning console-setup for squeeze? - Debian

This is a discussion on plans concerning console-setup for squeeze? - Debian ; [please cc me on any replies as I'm not on -boot] Hi, I'm wondering whether there are any plans to install console-setup by default in the squeeze time frame? It would be nice to have only one place to setup ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: plans concerning console-setup for squeeze?

  1. plans concerning console-setup for squeeze?

    [please cc me on any replies as I'm not on -boot]

    Hi,

    I'm wondering whether there are any plans to install console-setup by
    default in the squeeze time frame?
    It would be nice to have only one place to setup keyboard settings for
    both X and the console, and as we'll be migrating that away from
    xorg.conf for the Xorg input-hotplug stuff anyway, I wonder if I should
    move the settings from xorg.conf to /etc/default/console-setup when
    upgrading X, and use that file to determine the layout in hal/X.
    For initial installs, I'll still need something to set the layout,
    which means either keep doing it in xserver-xorg.postinst, or rely on
    console-setup doing it for me. Obviously I prefer the second option

    Thanks in advance for your comments,
    Julien


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: plans concerning console-setup for squeeze?

    Quoting Julien Cristau (jcristau@debian.org):
    > [please cc me on any replies as I'm not on -boot]
    >
    > Hi,
    >
    > I'm wondering whether there are any plans to install console-setup by
    > default in the squeeze time frame?
    > It would be nice to have only one place to setup keyboard settings for
    > both X and the console, and as we'll be migrating that away from
    > xorg.conf for the Xorg input-hotplug stuff anyway, I wonder if I should
    > move the settings from xorg.conf to /etc/default/console-setup when
    > upgrading X, and use that file to determine the layout in hal/X.
    > For initial installs, I'll still need something to set the layout,
    > which means either keep doing it in xserver-xorg.postinst, or rely on
    > console-setup doing it for me. Obviously I prefer the second option



    There were plans to *use* console-setup in D-I instead of kbd-chooser
    and console-data udebs. They would have resulted in c-s being used on
    the installed system as well.

    There is even a wiki pakge in the DebianInstaller tree about this.

    The plan choke on two things, so far:

    - i18n of the keymap questions (keymap names), which would be a
    regression
    - having someone really caring about this *and* being skilled enough
    in those things to be able to commit self to conduct the transition
    *and* maintain c-s afterwards

    So, I think that everybody agrees on the *principle*...now we need to
    find the resources to actually do it.

    and that would make me very happy as the current mess of
    console-tools, console-common, kbd and console-data is a nightmare,
    particularly considering that most of these are in maintenance mode.




    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjZEzsACgkQ1OXtrMAUPS1uRwCfQG+BgQtzJx eQYsUwHvFSgnvo
    VoAAnA7KEjweDjy/WY9jwz5VDpbELIkW
    =aD25
    -----END PGP SIGNATURE-----


  3. Re: plans concerning console-setup for squeeze?

    On Tuesday 23 September 2008, Christian Perrier wrote:
    > The plan choke on two things, so far:
    >
    > - i18n of the keymap questions (keymap names), which would be a
    > regression
    > - having someone really caring about this *and* being skilled enough
    > in those things to be able to commit self to conduct the transition
    > *and* maintain c-s afterwards


    Wasn't there also the issue that the console-setup + kbd udebs are rather
    large when compared to kbd-chooser?

    What also needs to be done is to check the console-setup functionality
    against the existing functionality in kbd-chooser, for example for serial
    console installs and headless systems.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkjZK+YACgkQgm/Kwh6ICoS7tACgpqnZrb9/128dO66gXIza2XMD
    iiMAoJSR/VO8mfOdZfKAFxFsdrMKeHKn
    =J162
    -----END PGP SIGNATURE-----


  4. Re: plans concerning console-setup for squeeze?

    On Tue, Sep 23, 2008 at 18:03:16 +0200, Christian Perrier wrote:

    > There were plans to *use* console-setup in D-I instead of kbd-chooser
    > and console-data udebs. They would have resulted in c-s being used on
    > the installed system as well.
    >
    > There is even a wiki pakge in the DebianInstaller tree about this.
    >
    > The plan choke on two things, so far:
    >
    > - i18n of the keymap questions (keymap names), which would be a
    > regression


    Would the existing translations from xkeyboard-config be useful there,
    or would we need to start all over? Granted, that's probably not as
    widely translated as d-i.
    Anyone knows how ubuntu handled this? I hear they use c-s already.

    > - having someone really caring about this *and* being skilled enough
    > in those things to be able to commit self to conduct the transition
    > *and* maintain c-s afterwards
    >

    OK. I don't really know what's involved in maintaining c-s, and I
    expect my free time will shrink in the next months (and X is enough of a
    big beast to make me not want to take on anything else), so I'm not
    volunteering, but I'd be happy to help whoever does.

    > So, I think that everybody agrees on the *principle*...now we need to
    > find the resources to actually do it.
    >
    > and that would make me very happy as the current mess of
    > console-tools, console-common, kbd and console-data is a nightmare,
    > particularly considering that most of these are in maintenance mode.
    >

    Thanks for the summary of the situation.

    Cheers,
    Julien


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: plans concerning console-setup for squeeze?

    Hello,

    Julien Cristau, le Wed 24 Sep 2008 12:29:07 +0200, a écrit :
    > On Tue, Sep 23, 2008 at 18:03:16 +0200, Christian Perrier wrote:
    > > - having someone really caring about this *and* being skilled enough
    > > in those things to be able to commit self to conduct the transition
    > > *and* maintain c-s afterwards
    > >

    > OK. I don't really know what's involved in maintaining c-s, and I
    > expect my free time will shrink in the next months (and X is enough of a
    > big beast to make me not want to take on anything else), so I'm not
    > volunteering, but I'd be happy to help whoever does.


    I would volunteer to work on it.

    Samuel


    --
    To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: plans concerning console-setup for squeeze?

    Quoting Julien Cristau (jcristau@debian.org):

    > > - i18n of the keymap questions (keymap names), which would be a
    > > regression

    >
    > Would the existing translations from xkeyboard-config be useful there,
    > or would we need to start all over? Granted, that's probably not as
    > widely translated as d-i.
    > Anyone knows how ubuntu handled this? I hear they use c-s already.


    I was really talking about *i18n*. Currently, in console-setup, the
    keymap names are not translat*able* (and therefore not translated, of
    course).

    This is where the blocker is lying. If the keymap names are
    internationalized, then we will be able to re-use any existing
    translations and, anyway, translators will have the entire
    lenny-squeeze release cycle to make the translations.

    Ubuntu doesn't offer a list of keymap names. Their installer prompts
    user to type some keys on their keyboard, grabs the returned keycode
    and, with a decision tree, finally decides what keymap to use.

    This is very smart but Colin Watson always said that the code behind
    this is "a ugly hack" (or something similar).




    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjaZnUACgkQ1OXtrMAUPS2ixQCggNLLOKQ6Cl HMKYUupIHQLfGS
    kZwAnRZmDreRPZpIrC7NOjFoMQ+LGjBH
    =x74e
    -----END PGP SIGNATURE-----


+ Reply to Thread