Re: [Tails-dev] Testing tails-greeter in Wheezy's Debian Live
Do you think I should stay subscribed? Or do I just wait for e.g. two months so that you are not so busy and I try again? I guess you are trying to release an stable Tails. Thank you for pinging back. adrian15 El 07/02/15 a las 12:49, intrigeri escribió: adrian15 wrote (07 Feb 2015 11:11:36 GMT) : (I am sending this message again. The first time I sent it I received no response whatsoever from tails-greeter people. [...]) Sorry for the delay, we're super busy. Cheers, -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/ ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
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
Re: [Tails-dev] Testing tails-greeter in Wheezy's Debian Live
adrian15 wrote (07 Feb 2015 11:11:36 GMT) : (I am sending this message again. The first time I sent it I received no response whatsoever from tails-greeter people. [...]) Sorry for the delay, we're super busy. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Testing tails-greeter in Wheezy's Debian Live
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
