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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
