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
