Re: [Tails-dev] Testing tails-greeter in Wheezy's Debian Liv…

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: adrian15
CC: tails-dev
Assumptes vells: [Tails-dev] Testing tails-greeter in Wheezy's Debian Live
Assumpte: Re: [Tails-dev] Testing tails-greeter in Wheezy's Debian Live
Hi Adrian,

adrian15 wrote (26 Nov 2014 01:38:14 GMT) :
> How to test tails-greeter
> --------------------------
> (This is not needed because you can test it in Rescatux 0.32b3. I still reuse it from
> Debian Live mailing list original email so that you see what the problems when you
> want to use your greeter as-is in Wheezy Debian Live).


> So, here there are the needed steps for making tails-greeter to work in a Wheezy
> LXDE's Debian Live CD (Rescatux 0.32b2 specifically). As it's LXDE based you might
> need to adapt the lightdm stop of another dm.


> [...]


Thanks. Do you expect us to do something specific about this?

> Questions about tails-greeter
> -----------------------------


> 1) Both:


> Supported language codes: /usr/share/tails-greeter/language_codes
> Default language code: /usr/share/tails-greeter/default_languagecodes


> are saved at Tails build time (according to:
> /usr/lib/python2.7/dist-packages/tailsgreeter/config.py file).


> As I see these files are being generated when tails-greeter package is built.


> What I am to focus right now is in language_codes (all the possible ones).
> According to:
> https://git-tails.immerda.ch/greeter/tree/debian/rules?id=tails-greeter_0.8.5#n16
> you seem to build your list based on:
> /usr/share/i18n/SUPPORTED
> .


> My questions about language_codes are:


> 1.1) Are you excluding some keyboards on purpose or not ? If so, why? (Sorry I'm not
> very good at perl).


Assuming you're talking of:

    perl -n -E 'next unless m{_}xms;        \
                next if m{\@}xms;           \
                say $$1 if m{(.*?) [. ]}xms' \
       /usr/share/i18n/SUPPORTED     \
       | uniq                        \
       > $(DESTDIR)/usr/share/tails-greeter/language_codes


... then:

  * We're dropping anything that contains no "_" char. On my current
    sid system, that's "eo.UTF-8 UTF-8" and "eo ISO-8859-3". I don't
    remember why exactly, but git log -p or git blame may remember.
  * We're dropping anything that contains a "@" char.


> 1.2) Do the tails-greeter buil-dependencies ensure that all the packages that
> fullfill the different keyboard layouts at: /usr/share/i18n/SUPPORTED/ are installed
> previous to the build?


/usr/share/i18n/SUPPORTED is shipped by the "locales" package.
tails-greeter build-depends on that package. Should be enough.

> My questions about default langcodes are:


> 1.3)


> https://git-tails.immerda.ch/greeter/tree/default_langcodes?id=tails-greeter_0.8.5


> Is there any rationale for choosing these ones over the rest of them?


The message for the commit that introduces this file explains where it
comes from :)

> About my fork and more questions about tails-greeter
> ----------------------------------------------------


> So I have made a tails-greeter fork so that it could work adapt and use it right now
> in Rescatux.


> 1) You can find the fork at:


> https://github.com/adrian15/tails-greeter/tree/rescatux_0.32


> 2) You can try the fork by testing the latest Rescatux 0.32 beta 3 here:


> http://www.supergrubdisk.org/2014/11/24/rescatux-0-32-beta-3-released/


> 3) How do you want to share source code?
> 3.1) At runtime thanks to a variable that depends on finding exclusive files found at
> Tails live cd? (Kind of what I draft on my fork).
> 3.2) With a build time variable that generates one type of package or antoher?
> 3.3) Trying to split the greeter into two parts, two packages (backend + frontend) so
> that I only have to code my own frontend different than ours but share the languages,
> country and keyboard layout algorithms?
> 3.4) Maybe another approach?


I've had a look at your changes, and it seems to me that making these
bits configurable at runtime (3.1) is the best way to go.

> 4) While doing my tests I have noticed an error similar to this one (I would have to
> reproduce it to give you the exact error):


> locale: Cannot Set LC_ALL to default locale: No such file or directory.


> if try to run gparted from a root console.


> If I checked with locale I saw that locale was something like:


> en_US.ansi_x3


> That's why I added the two commands for forcing the generation of the used locale.


We ship locales-all in Tails, so we have the guarantee that the chosen
locale is generated already. I'm afraid that dynamically generating
locales at PostLogin time will introduce a large waiting time without
any feedback to the user. Maybe we should simply make tails-greeter
depend on locales-all. What do you think?

> 5) Is there a way in your glade translation to replace Tails with a variable so that
> when the distro is not Tails you do not have to translate it all over again but just
> change the variable value ?


The two strings that contain "Tails" in po/tails-greeter.pot could
indeed have the OS name as a placeholder that the code could replace
at runtime. Patches welcome :)

> 6) I would like to rewrite the greeter in QT but I don't have time and I don't
> it's worth.


This looks like a technical solution that's looking for a problem it
could solve, but maybe once you explain why you want Qt, I'll
understand better :)

Tails is based on GNOME, so using GTK ensures better integration in
the rest of our environment, and possibly faster startup also.

> 7) I would probably try to the greeter with only lightdm and not gdm3 and see how it
> goes. This could be another improvement over tails-greeter, to make it
> dm independent.


Hmm, wow. Why not. I think the abstraction layer you'll want to insert
will need to be pretty well thought, in order to avoid having it
introducing too much complexity and hard to debug bits.

> Finally I want to give you a big thank you for tails-greeter.


:)

Cheers,
--
intrigeri