(I am sending this message again. The first time I sent it I received no
response whatsoever from tails-greeter people. If I don't get any
feedback I will unsubscribe from the mailing list (which it's the only
reason I'm subscribed here) and I will try to maintain this fork on my
own and I'm lucky enough to convert it into a QT application.)
Note: Just in case it does not make sense I'm reusing an email that I
sent originally to Debian Live mailing list. So the first part of it
it's addressed to Debian Live people.
Introduction
------------
As you might know I'm interested in the final user being able to
choose a keyboard from a menu. And that should work in Debian Live by
default. (
https://lists.debian.org/debian-live/2014/10/msg00056.html )
I finally made my mind to use tails-greeter as a base for this
specific requirement (
https://lists.debian.org/debian-live/2014/11/msg00041.html) and this
email explains my findings and doubts about it.
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.
These instructions are meant for using them once your original Debian
Live CD has booted. They are not meant for setting up your Debian Live
config and rebuild it.
1. Create:
/etc/apt/sources.list.d/tails.list
with:
deb
http://deb.tails.boum.org/ 1.2 main
2. Run:
apt-get update
3. apt-get install tails-greeter
When prompted choose gdm3 instead of the default lightdm
4.
Create a fake live-persist at:
/usr/local/sbin/live-persist
with:
#!/bin/bash
exit 0
and give it execution permissions:
chmod +x /usr/local/sbin/live-persist
5. Edit default user
Edit:
/usr/lib/python2.7/dist-packages/tailsgreeter/config.py
and change
LUSER = 'amnesia'
to:
LUSER = 'user'
6. Apply changes with (probably better at CTRL+ALT+F1):
service lightdm stop
service gdm3 start
7. Be patient.
At the bottom you can change the keyboard then you click on Login button
8. The usual desktop appears and you have keyboard setup !
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).
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?
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?
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?
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.
I'm asking myself if it's a problem because I use libc6 from jessie
instead of wheezy or if it's something extra that your greeter does that
I never came across.
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 ?
6) I would like to rewrite the greeter in QT but I don't have time and I
don't it's worth.
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.
More information
----------------
The instructions above imply that you have to replace lightdm by gdm3.
That's not strictly needed if you know how to replace the default
lightdm greeter.
Hopefully we can decide how we can work together so that something like
a live-greeter can be available.
I also know about your pretty mockups :). That's another reason why
using Tails greeter, because the language selection will be fancier.
Finally I want to give you a big thank you for tails-greeter.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk.
http://www.supergrubdisk.org/donate/
