Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi again, Also I just notices intrigeri asked you a late question about your last week report on the tails-dev mailing list without any answer. Please see his last mail to you and tails-dev from August 04 about using a shell script. Did you answer to this question privately? bert. On Fri, Aug 05, 2011 at 05:25:22PM +0200, berta...@ptitcanardnoir.org wrote: Hi, I'm trying to catch up on this GSOC work, so I might be lacking some informations to correctly understand everything. Don't hesitate to correct me if I make any mistake. I've tested your previous 0.0.5 release as well as this week's one in a fresh VM, and read your previous exchanges with intrigeri. On Fri, Aug 05, 2011 at 02:15:52AM +0800, † wrote: Hello. Current progress: obtain list of kb layouts and variants available (via python-xklavier) - DONE. populate layout widget with kb variants - DONE. merge feature/better_root_access_control branch - DONE. Confirm the above three DONE items. Well done! apply correct layout after it's been chosen (both to present and following greeter widgets and to actual session) - postponed. verify that layout switching works after login - postponed version tag and update - DONE. As I understood, you were also supposed to upload a Debian package to your tails repo, which I can't find. Problems: tails-greeter is run under gdm's account but altering gdm PostLogon files (to set env variables) or locale compilation via localedef require root privileges. Seems like intrigeri already proposed a workaround to this last week, please read again his answer to your report last week. xklavier set and check layout without errors but it doesn't affect greeter nor following session. better_root_access_control feature requires env. variable to be set which is not possible yet. Near-future plans: wait for answer from gdm and xklavier devs to figure out workarounds for current problems Do you have pointers to this conversation? I might be interested to follow it, and eventually help you with it. replace 2 widgets with 1 panel with same functionality test the result with tails Sounds to me that the next step to this dev would be to implement a way to pass env variables too. Additional notes: right now there are 2 screens which user moves through by pressing next button. That's rather ugly and is planned to be replaced with one of the following: 1) single screen with requests for both at the same time 2) 2 screens with language and layout requests on first one and admin password request on second one Which do you think is better and why? Please feel free to discuss it on irc this Saturday during regular meeting time or whenever you'll see max-gsoc I think intrigeri already made that clear when you started with 2 screens that at the end we wanted to have only one screen with all options on it. We don't want to bother too much our users with multiple screens. Another question: reading your commits, you removed the babel module importation. Do you plan to put it back, or are you just getting rid of it? In the latter case, you should also consider removing it from the install dependencies of the Debian package in debian/control. See you tomorrow morning. bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
On Sat, Aug 06, 2011 at 12:24:36AM +0800, † wrote: 05.08.2011 23:53, berta...@ptitcanardnoir.org пишет: Also I just notices intrigeri asked you a late question about your last week report on the tails-dev mailing list without any answer. Please see his last mail to you and tails-dev from August 04 about using a shell script. Did you answer to this question privately? He departed to vacation before that. In short - yes, rewriting sh to python is doable but the code which supposed to be rewritten is (or, to be more precise - will be) obsolete after some workaround to pass env. vars will be implemented anyway. Fair enough. We'll see if such a workaround exists though. bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
On Sat, Aug 06, 2011 at 12:38:24AM +0800, † wrote: 05.08.2011 23:25, berta...@ptitcanardnoir.org пишет: As I understood, you were also supposed to upload a Debian package to your tails repo, which I can't find. Sorry, forgot to push it. Should be available now. Seems not really, can't find any new commit with the new Debian package. Seems like intrigeri already proposed a workaround to this last week, please read again his answer to your report last week. Just to get potential readers up-to-date: the idea is following tails-greeter writes some instructions (env. variables, locale generation parameters smth else) to the place writable for it's user (Debian-gdm) for example. Upon logon some startup script parse this file and execute them (as amnesia user or as root). That'll be next thing I'll try to implement and that's actually what I'd like to discuss: So that maybe should be added to your schedule for next week, it was my suggestion in my last email. - how good\safe is this approach? Using such tricks to have something executed by root might sure bring the question, and that's nice it pops up in your head. But well, we're talking about mostly predefined choices, and run once during the system boot time. I'm not sure to see what an attacker could do to take advantage of this and s/he is able to do this, s/he can do a lot more. - are there better alternatives? I'm out of idea for the moment, but will sleep on this. Note that at least some of the instructions from this file got to be executed with root privileges. Just to clarify: by executed I don't mean sh file.sh - it might be $ARG1 supplied to sudo ls $ARG1. Do you have pointers to this conversation? I might be interested to follow it, and eventually help you with it. http://mail.gnome.org/archives/gdm-list/2011-August/msg2.html Thanks. Looks like for the moment they don't really have answers to your issue, we'll see in the next days, but I suspect you won't have much choices. replace 2 widgets with 1 panel with same functionality test the result with tails Sounds to me that the next step to this dev would be to implement a way to pass env variables too. Not really sure what you mean. If you're talking about task priorities than - yes, that's true. The tasks are orthogonal though. I meant: add to the next week plan the work on implementing a way to pass env variables to the session. I'm not sure to get why this two tasks are orthogonal, I rather feel that the env thing is not that much related to how the widget/panel are organized and can be developed independently from the other one. But maybe I'm wrong and missing the big picture, and would be glad to have your input in this case. It seems that there is not much time left before the end of your GSOC, and this is a critical piece of the project I'd like to see getting forward. I'm not asking for this task to be completely done at the end of next week, but given the time spent on the GSOC your commits seems to reveal, I'd prefer to see some work going on in this area, and the plan you posted initially might have some room left to add it. But sure the panel reorganisation is also important. :) Another question: reading your commits, you removed the babel module importation. Do you plan to put it back, or are you just getting rid of it? In the latter case, you should also consider removing it from the install dependencies of the Debian package in debian/control. That was just part of pylint warnings cleanup. I didn't notice that it's completely gone now :) Great! bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi Max, I just found an unfinished email to you from last week in my drafts folder. Here are bits that are still relevant I believe. About the environment variables passed to the user session, I wonder why this is implemented in such a complicated way; I'm talking of the tails-env-helper + command line arguments thingie. Copying a file and appending lines to it should be done directly in Python, rather than by passing arguments to a helper program written in shell: the way it is currently implemented, if done right, requires you to deal with a well-known, rarely got right, problem: shell quoting; you really don't want to do that I believe, and the fact the current implementation does not deal with this issue at all is a big hint. Moreover, doing it in Python will make it much easier to support passing multiple envvars, which the current code does not support. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
intrigeri wrote (16 Jul 2011 18:17:01 GMT) : So I think a best bet is to go directly the long term way, and have the backend support the usecase described above. In that case, the only needed UI change is the removal of the warning text. For the record, Max fixed the backend. The UI consistency change is still missing, though. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | The impossible just takes a bit longer. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi, † wrote (15 Jul 2011 19:20:53 GMT) : 15.07.2011 23:19, intrigeri пишет: Since there is still no new tag in the Git repository, and no mention of a particular commit we should look at, I'm testing the current state of the Git repo (commit 8c6f2609c). I've sent private email with subj please test 0.0.3~6.gbpa1b424 on 12.07 but recent repo is definitely better. Indeed. I am sorry I wasn't responsive to your asking me to test your code on Tuesday; in the future, I suggest posting such requests on the tails-dev mailing-list, which is no more work for you, but increase the chances someone catches the ball and has a look to your results. On the other hand, when I review on Friday what you've done this week after reading your weekly report, I don't expect to test the code in the state you pointed me to on Tuesday; isn't it obvious? So the only way I can feel your reply is called nitpicking, and I don't like communicating like this. Almost every week from the beginning of the GSoC coding time, I've explained in length the need for a new clearly tagged version explicitly mentionned in your report; this is the why. Also, we have spent one hour going through a great part of the release process together on IRC today, so I think the how is covered as well. I am thus confident you'll eventually do better next week at report time :) Also, the UI has a note that reads the selection cannot be changed once you press the button; while this seems to be technically correct (according to the debug log, selecting a language for the second time triggers actions relative to the first chosen language), it's very confusing UI-wise to read this, while being able to choose a language once again, despite what the message says. If tails-greeter does not support choosing the language a second time (which I suggested initially to ease your task), great, but the UI must reflect it. I don't get it completely - probably smth wrong with my English. Thank you for splitting the problem into smaller pieces. a) Does UI behave the way it should right now? If not - what's the expected difference? It depends on the short/long term perspective and on implementation complexity. I'm talking of the following usecase: user selects language A, then changes her mind and selects language B, both before clicking the Forward button. Currently, the backend does not support this usecase: according to the debug log messages, the action of selecting language B has no effect, which is obviously inconsistent UI-wise. If it's hard to properly support this usecase, then OK, let's not support it to begin with; it seems to be what you decided to do; but in that case, the UI must be changed to be consistent and understandable: 1. the user must not be able to use more than once the widget that allows her to select a language. 2. selecting a non-default language should be enough to go forward; clicking the Forward button should only be needed when using the default language. On the other hand, making the UI consistent this way, in order to palliate backend limitations, needs probably as much work as fixing the root cause of the problem, i.e. the backend limitations themselves. So I think a best bet is to go directly the long term way, and have the backend support the usecase described above. In that case, the only needed UI change is the removal of the warning text. What do you think? b) Does explanation text misleading? If yes - which one you'd like to see instead? See above. It would be great if the interface between this script and tails-greeter was documented on the wiki: https://tails.boum.org/todo/TailsGreeter/#index4h2 I've added it (with small cleanup) but it's preliminary anyway: we got to figure out what do we do about non-utf8 encodings so this might be changed even in near future. Nice start, but insufficient to describe the interface I think: you describe what information is transmitted (i.e. locale name), but you don't describe how it is transmitted (i.e. first argument to the program). And just to make sure I won't forget about it till when: right now there is no difference in UI between languages tails-greeter support and languages which are supported only by the system. So the user can choose 'chinese', click next and still see 'english' on the next widget(s). This is probably wrong as well and deserve further discussion. Do you mean and see English text on the next widget(s)? If so, I don't think it's a problem. I bet speakers of language X prefer to get their GNOME interface and web browser in the X language rather than English fallback, regardless of whether tails-greeter is 100% translated into X or not. See you on Monday, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Who wants a world in which the guarantee that we shall not
Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi, I'm in the process of reviewing and testing the work you did this week. Since there is still no new tag in the Git repository, and no mention of a particular commit we should look at, I'm testing the current state of the Git repo (commit 8c6f2609c). Let me start with reiterating some stuff I've already mentioned over private email a few days ago, without effect yet: lintian overrides: I still think you should merge my lintian branch and revert the broken half-merge that was done, as well as the dirty workaround you put in when you saw the half-merge was breaking stuff. Translation: please remove the attempt at a French translation; it'll be easy to find someone to do a proper translation once strings have settled. Having wrong translations prevent the .po file from showing up as needing work. Let me now comment on your progress report. I'm grouping related things together, so the lines you wrote are reordered bellow. ## Current progress: - populate language list using list of available locales in /usr/share/i18n/SUPPORTED - DONE. - Language list should contain language's own name (e. g. 'Русский' for Russian') instead of current 2-letter code - DONE. - use existing code/UI from d-i/anaconda/ubuntu installer/ for language chooser if possible - partially done (PyICU utilized). Great to see the language list is now dynamically built. However, the sorting is wrong since some languages have their name capitalized, while others haven't. This is very disturbing, and it took me some time understanding why the language I was looking for was not in the list. This kind of issues is the reason why I've repeatedly suggested to base your work on existing code that does the right thing, instead of spending time reinventing that wheel and doing it wrong at the end of the day. Also, the UI has a note that reads the selection cannot be changed once you press the button; while this seems to be technically correct (according to the debug log, selecting a language for the second time triggers actions relative to the first chosen language), it's very confusing UI-wise to read this, while being able to choose a language once again, despite what the message says. If tails-greeter does not support choosing the language a second time (which I suggested initially to ease your task), great, but the UI must reflect it. - supply parameter as 'en' (or smth else suitable for locale generation - investigate) to locale-gen - DONE. Great. It would be great if the interface between this script and tails-greeter was documented on the wiki: https://tails.boum.org/todo/TailsGreeter/#index4h2 - translate language widget too (move lang choice handler from button_clicked to list_choice) I see you've done it since you sent your report, but I could not see it working. Maybe the .pot/.po files must be updated to check it's actually working? How do I update the .pot/.po files if I don't want to wait for you to do it everytime? - Move locale-gen interaction to greeter from widget - DONE. Great. - cleanup commented\old\dead code - DONE. Great (well, you did it the week before actually, but why not). [... snipped postponed items ...] ## Problems: - Some of the 'native' language names are not displayed correctly due to missing characters in the fonts (standard unicode squares shown instead). It's unclear how to filter them out because there are no actual errors shown in python. Please don't spend any more time looking for a way to filter these languages out. Preventing anyone from using Tails in Chinese would be no way to fix the actual problem, but rather a way to hide it under the carpet. Anyway, installing the ttf-unifont package fixes this issue for me. The glyphs are not that nice, but at least they are readable and usable I believe. You probably should add this package as a dependency of tails-greeter (debian/control). - The language list is fairly long: maybe some of the exotic languages could be filtered or black-listed before list population? The list of languages spoken by human being is fairly long indeed, he he. If the list appears too long, maybe the widget (that only uses a small fraction of the available screen estate) is suboptimal. I'd be sad removing languages from the list just to make it appear shorter, and I'd rather not have to decide what language is exotic and what other is not. I suggest you let the current list alone and start a dedicated discussion thread about this on tails-dev, providing a summary of all information and numbers that are relevant to the discussion, since I don't feel like deciding alone on this matter. If we really end up support less languages, we need to list the ones we want to support, instead of the ones we don't want to. E.g. we could use the list of iceweasel l10n packs in Debian (apt-cache search 'iceweasel-l10n-*' | wc -l = 79 results). - It's yet unclear how to pass information to the session initiated by gdm: especially
Re: [Tails-dev] [gsoc] tails-greeter progress report
15.07.2011 23:19, intrigeri пишет: I'm in the process of reviewing and testing the work you did this week. Since there is still no new tag in the Git repository, and no mention of a particular commit we should look at, I'm testing the current state of the Git repo (commit 8c6f2609c). I've sent private email with subj please test 0.0.3~6.gbpa1b424 on 12.07 but recent repo is definitely better. lintian overrides: I still think you should merge my lintian branch and revert the broken half-merge that was done, as well as the dirty workaround you put in when you saw the half-merge was breaking stuff. I've added it to timeline. Translation: please remove the attempt at a French translation; it'll be easy to find someone to do a proper translation once strings have settled. Having wrong translations prevent the .po file from showing up as needing work. To be honest I think 'original' English text require revision as well and I prefer to have more than one translation for the sake of testing so I'll add FIXME to translations. However, the sorting is wrong since some languages have their name capitalized, while others haven't. This is very disturbing... I completely agree. I'm looking into ubiquity code right now - it seems to be the closest thing to what we want. Also, the UI has a note that reads the selection cannot be changed once you press the button; while this seems to be technically correct (according to the debug log, selecting a language for the second time triggers actions relative to the first chosen language), it's very confusing UI-wise to read this, while being able to choose a language once again, despite what the message says. If tails-greeter does not support choosing the language a second time (which I suggested initially to ease your task), great, but the UI must reflect it. I don't get it completely - probably smth wrong with my English. a) Does UI behave the way it should right now? If not - what's the expected difference? b) Does explanation text misleading? If yes - which one you'd like to see instead? It would be great if the interface between this script and tails-greeter was documented on the wiki: https://tails.boum.org/todo/TailsGreeter/#index4h2 I've added it (with small cleanup) but it's preliminary anyway: we got to figure out what do we do about non-utf8 encodings so this might be changed even in near future. I see you've done it since you sent your report, but I could not see it working. Maybe the .pot/.po files must be updated to check it's actually working? How do I update the .pot/.po files if I don't want to wait for you to do it everytime? This is definitely wrong: all necessary files should be in git already and it works for me (that's why I've marked it as 'done' :) We should investigate why it fails for you. - cleanup commented\old\dead code - DONE. Great (well, you did it the week before actually, but why not). Yepp, I've marked it as done last week as far as I recall. Anyway, installing the ttf-unifont package fixes this issue for me. The glyphs are not that nice, but at least they are readable and usable I believe. You probably should add this package as a dependency of tails-greeter (debian/control). Awesome, I'll test it and push tonight. The list of languages spoken by human being is fairly long indeed, he he. If the list appears too long, maybe the widget (that only uses a small fraction of the available screen estate) is suboptimal. I'd be sad removing languages from the list just to make it appear shorter, and I'd rather not have to decide what language is exotic and what other is not. I suggest you let the current list alone and start a dedicated discussion thread about this on tails-dev, providing a summary of all information and numbers that are relevant to the discussion, since I don't feel like deciding alone on this matter. Ok, I'll send separate email some time next week when I better understand things like 'variants'. And just to make sure I won't forget about it till when: right now there is no difference in UI between languages tails-greeter support and languages which are supported only by the system. So the user can choose 'chinese', click next and still see 'english' on the next widget(s). This is probably wrong as well and deserve further discussion. If we really end up support less languages, we need to list the ones we want to support, instead of the ones we don't want to. E.g. we could use the list of iceweasel l10n packs in Debian (apt-cache search 'iceweasel-l10n-*' | wc -l = 79 results). Valid option too. I'm sure it can be cleared by looking at the gdm-simple-greeter code. Looking into it too. On this topic, the main resource I suggested was gdm-simple-greeter. Even if you don't reuse code, these existing pieces of software will at least show you how this issue is generally dealt with, i.e. what users may expect (principle of least surprise).
[Tails-dev] [gsoc] tails-greeter progress report
Hello. ## Current progress: - populate language list using list of available locales in /usr/share/i18n/SUPPORTED - DONE. - supply parameter as 'en' (or smth else suitable for locale generation - investigate) to locale-gen - DONE. - Language list should contain language's own name (e. g. 'Русский' for 'Russian') instead of current 2-letter code - DONE. - translate language widget too (move lang choice handler from button_clicked to list_choice) - Move locale-gen interaction to greeter from widget - DONE. - cleanup commented\old\dead code - DONE. - obtain list of kb layouts available (via python-xklavier) - use existing code/UI from d-i/anaconda/ubuntu installer/ for language chooser if possible - partially done (PyICU utilized). - apply correct layout after it's been chosen (both to present and following greeter widgets and to actual session) ## Problems: - Some of the 'native' language names are not displayed correctly due to missing characters in the fonts (standard unicode squares shown instead). It's unclear how to filter them out because there are no actual errors shown in python. - The language list is fairly long: maybe some of the exotic languages could be filtered or black-listed before list population? - It's yet unclear how to pass information to the session initiated by gdm: especially how to set env. variable and apply language layout settings - probably there are some dbus hooks available. - xklavier and ICU seems like the right way to work with language and layout data but there is no obvious way to reuse code from installers (anaconda, d-i) directly. ## Near-future plans: - Make widget for layout choice and populate it with data obtained via xklavier. - Create version suitable for .iso build and test. - Next week plans. ## Additional notes: - Part of the code has been merged back to gdm-community-greeter project via special branch. - The issue with wrongly displayed language names might be related to legacy (non-utf8) encodings. Right now there is no special treatment for those encodings. It's unclear whether some support required in tails-greeter for that at all. - The general 'id' for the locale looks like ru_RU (language-country code) - see 'man localedef'. What's the acceptable id for layout is still unclear. cheers, Max. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
08.07.2011 17:03, intrigeri пишет: If tails-lang-helper and tails-locale-gen are for internal use only, which seems to be the case, they probably should be installed to /usr/share/ rather than /usr/bin/. If they are installed into directory which is not part of $PATH than I have to use full path to run them from python. Any reason to have the .desktop file weirdly named a-tails-greeter.desktop? IIRC this was an old attempt to have it run before gdm-simple-greeter, that you disable using dpkg-divert nowadays. Yepp, should be fixed now. python-support is now deprecated¹. The Debian packaging will need to be converted at some point; see dh_python2(1) for details. Low-priority, though. I've added it to timeline. Current Git code crashes at runtime since you renamed the helper scripts without updating the code that run them. Ah, forgot about it, sorry. Please set debian/source/format to 3.0 (native) (lintian missing-debian-source-format info message). Done. You probably have noticed it already, but just in case: your lintian overrides don't work at all, presumably because you applied them to the source package while lintian is concerned with the binary package. That's what I was going to discuss during during today's meeting :) cheers, Max. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi, † wrote (09 Jul 2011 07:20:14 GMT) : 08.07.2011 17:03, intrigeri пишет: Any reason to have the .desktop file weirdly named a-tails-greeter.desktop? IIRC this was an old attempt to have it run before gdm-simple-greeter, that you disable using dpkg-divert nowadays. Yepp, should be fixed now. Almost. That's what git grep is for: $ git grep a-tails-greeter.desktop MANIFEST.in:include a-tails-greeter.desktop You probably have noticed it already, but just in case: your lintian overrides don't work at all, presumably because you applied them to the source package while lintian is concerned with the binary package. That's what I was going to discuss during during today's meeting :) Real-world example of lintian overrides applied to binary packages: https://gitweb.torproject.org/debian/tor.git/tree/HEAD:/debian (look for *.lintian-override). bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi, here are some more comments, in addition to the bunch of private email I've already sent you. If tails-lang-helper and tails-locale-gen are for internal use only, which seems to be the case, they probably should be installed to /usr/share/ rather than /usr/bin/. Any reason to have the .desktop file weirdly named a-tails-greeter.desktop? IIRC this was an old attempt to have it run before gdm-simple-greeter, that you disable using dpkg-divert nowadays. python-support is now deprecated¹. The Debian packaging will need to be converted at some point; see dh_python2(1) for details. Low-priority, though. ¹ http://lists.debian.org/debian-python/2011/06/msg00136.html Current Git code crashes at runtime since you renamed the helper scripts without updating the code that run them. Once I've (trivially) fixed autologin.py and language.py in my local Git repo, your current Git branch (at 82c1d0e9) is still crashing: [DEBUG] language.py:36 module: 144 languages found: helper returned 0 Traceback (most recent call last): File ./community-greeter.py, line 44, in module from GdmGreeter.language import Translatable File /usr/lib/pymodules/python2.6/GdmGreeter/language.py, line 37, in module LANGS = map(lambda x: babel.Locale.parse(x), langcodes) File /usr/lib/pymodules/python2.6/GdmGreeter/language.py, line 37, in lambda LANGS = map(lambda x: babel.Locale.parse(x), langcodes) File /usr/lib/pymodules/python2.6/babel/core.py, line 212, in parse return cls(*parse_locale(identifier, sep=sep)) File /usr/lib/pymodules/python2.6/babel/core.py, line 137, in __init__ raise UnknownLocaleError(identifier) babel.core.UnknownLocaleError: unknown locale 'an' So I cannot test much further. Hence the need to have tagged known-working, please test this one snapshot pre-releases. Reverting 82c1d0e9 makes the whole thing working, but only proposes the English language due to the issue 82c1d0e9 was trying to fix. Please set debian/source/format to 3.0 (native) (lintian missing-debian-source-format info message). You probably have noticed it already, but just in case: your lintian overrides don't work at all, presumably because you applied them to the source package while lintian is concerned with the binary package. By the way, the following set of lintian options will be of great help for learning: --info --display-info --pedantic --show-overrides Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
[Tails-dev] [gsoc] tails-greeter progress report
Hello. Current progress: - change widget exec order (parallel-sequential) to comply with localization notes part of design - DONE. - setup squid-deb-proxy - DONE. - make .iso build - DONE. - change widget to fit many more languages: from flag icons to scrollable list - DONE. - (re)generate .po with (dummy) translations (to show that language change is actually working) - DONE. - populate the list of supported languages in the widget from gnome-desktop-data package languages or dpkg-reconfigure locales (see gdm_get_all_language_names function for example) - DONE (with external helper script). - 'subprocess': run external (locale-gen) program with adequate parameters on language change and wait for its completion before allowing logon - in progress. - update tails-greeter.deb package - in progress. - propose rough plans / estimates for all the remaining weeks - postponed. Problems Current implementation uses gtk's ComboBox for the list of languages. Switching to scrollable list (similar to debian-installer) might require to scale better to bigger number of languages but it will take a bit more efforts to integrate it with gtkme wrapper. Pygtk functions for window.show() and window.hide() do not work as expected - sometimes window which supposed to be hidden remain visible despite successful gtk property change. Right now the workaround is to call window.destroy() however this might not scale that well if we will have multiple windows with complex interactions in between in future. To summarize: worth investigating but not top priority at the moment. Right now language list is presented to user based on the locales available in the system (e. g. those chosen via 'dpkg-reconfigure locales' for example). Those might be unsupported by available tails-greeter translations. And vice-versa: there might be tails-greeter translation which doesn't correspond to any system locale. Those situations got to be carefully tested and handled gracefully. Current implementation uses subprocess' calls to run locale generation from autologin widget - it should be moved to upper layer - to the greeter itself: it will be easier to incorporate other widgets this way. There are several ways to obtain list of supported locales in gdm/gui/simple-greeter/gdm-languages.c (including locale.alias file, gdm's locale-archive and system-wide locale-archive). Similar logic should be incorporated into tails-greeter. It's worth investigating if it's feasible to engage gdm code using ctypes for example. Near-future plans - Complete .iso build and tests, push new tails-greeter.deb if the tests are successful. - Investigate things listed in 'problems' section above - Implement plans for next week #7 Additional notes Right now language choice is applied only after user have pressed 'forward' button - it would look nicer if it's done immediately upon selection. Language list should contain language's own name (e. g. 'Русский' for 'Russian') instead of current 2-letter code. Those should be included into plans for some of the upcoming weeks. cheers, Max. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
[Tails-dev] [gsoc] tails-greeter progress report
Hi there :) Current progress - change widget to fit many more languages: from flag icons to scrollable list - partially done (see below). - make .iso build - not done (see below). - specify dbus interface to interact with external locale-gen script - in progress (see below). - change widget exec order (parallel-sequential) to comply with localization notes part of design - in progress. Problems - relocation to another country - .iso build fails (currently under investigation) - change of widget exec order and the interaction with locale-gen script both require rewrite of the d-bus code in services.py which cannot be completed during this week Near-future plans - rewrite d-bus handling in service.py - change widget exec order - substitute LanguageWindow widget with LangselectWindow - remainder of week #6 plans from timeline (https://tails.boum.org/todo/TailsGreeter/timeline/#index6h1) cheers, Max. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi, † wrote (24 Jun 2011 14:40:24 GMT) : 24.06.2011 12:34, intrigeri пишет: My pylint reports no error. Beware not letting the pile of warnings grow bigger and bigger, else it will prove difficult to sort these out once the code is bigger, working and lacking a testsuite. Indeed, no more errors. I've corrected wiki entry. The thing about warnings is that many of them are related to the parts of code which we do not use or even do not plan to use so there is not my point in correcting them right now. I'll try to fix them gradually although I guess it's rather low-priority task atm Then kill the unneeded code, and worry about the bits you don't use yet as incrementally, as soon as you start using (and probably adapting) it. Added benefit: it's a nice way to get to know the code you're re-using. and I'll try to keep the warnings to the minimum in new code. Great. I didn't get it working. Seems like it depends on some kind of USER_CONFIG (USER_CONFIG = '/home/users/%s.user') configuration file, whose exact path and content isn't documented on TailsGreeter/install; when I click one of the languages button, nothing interesting happens and :0-greeter.log displays: Ahh, great that you've found it, thanks! Should be fixed with latest git push. Indeed, it's fixed. Now you probably want to refresh the existing .po files that lack the strings you've introduced, generate some new .po files for the languages you current UI supports, put some dummy translations in there so that we can make sure the language buttons actually have the intended effect. Please explain in the design doc what current limitation requires the supported languages list (I guess this is what you mean by locales) to be known at build time. Please also sum up what possible solutions you've thought of along with their pros and cons. I've updated design page. Should be clearer now. Indeed it's clearer. IMHO, using different sets of available languages in tails-greeter and in the Tails GNOME session itself would be greatly confusing for users, and probably complicate the code needlessly. Both should IMHO at least minimally support every language supported e.g. by the Debian installer (or GNOME). I wonder why would we want to make these sets different the way you wrote on the design page. Any rationale I missed? I don't think so, see above. You indeed updated this early in the week, but the testing instructions must be *kept* up-to-date. Updated install instructions recently. Thanks. Please clarify disable default greeter by editing /usr/share/gdm/autostart/LoginWindow/gdm-simple-greeter.desktop there. Great idea. Have you already tried reaching the developer(s)? Yes, although it happened more early morning than late night due to time difference :) As a result login is working now although not via BeginAutoLogin feature but through regular user-auth procedure (hardcoded user password). I've tested BeginAutoLogin and it works too so probably I'll use it in near future. I couldn't make the login work. Are you sure this should work in the code you've published? Click Forward = black screen, blinking text-mode cursor. End of the log is: The application 'polkit-gnome-authentication-agent-1' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application. The application 'community-greeter.py' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application. Anyway, I have a question on add .deb to tails repo - how to do it? Do we integrate source package? Just drop the .deb i386 binary package into config/chroot_local-packages/. No need to add the source package as long as the binary package has enough information in it (repository location + proper versionning + Git commit id) so that anyone can have access to the source and reproduce the build. I've also added note about dpkg-divert - I'll take a look how to integrate it into .deb: now when we have working logon procedure it actually make sense to do earlier :) Right. I think I've emailed you some pointers to other packages that use dpkg-divert already, so digging into your INBOX should provide enough guidance to get you started. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
[Tails-dev] [gsoc] tails-greeter progress report
Hi there :) Current progress convert tails-greeter to old-style pygtk to remove pygi dependecy: [in progress] re-test converted version with squeeze: [done, test failed] check if current localization handling is suitable for tails-greeter: [postponed] make plans for next week: [done] Problems proper procedure for version increase errors with dbus after conversion dpkg-divert required for proper testing need easy way to run python syntax quick check on entire file Near-future plans add dpkg-divert functionality to .deb fix errors found after conversion run external (placeholder) program with adequate parameters on language change (locale generation for example) alter python code with dummy 'admin password requestor' add tails-greeter.deb into tails.git (main) repo add note that it's dangerous to install tails-greeter.deb :) cheers, Max. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
[Tails-dev] [gsoc] tails-greeter progress report
Hi there :) Current progress mostly work on university projects so minor fixes and updates only weekly meeting follow-up - multiple wiki updates review existing python code glade interfaces gdm-community-greeter forked into tails-greeter filed RFP for gtkme http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629199 - dependency for tails-greeter pbuilder fix: git-buildpackage successfully builds from 'master' granch run community-greeter in VM: partially done - see below Problems installation into debian-squeeze is fine but got runtime error due to old python-gobject package, no backports found check with debian-sid is due before weekly meeting Near-future plans complete VM testing play with d-feet dbus debugger alter python code with dummy 'admin password requestor' check if current localization handling is suitable for tails-greeter make plans for next week cheers, Max. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 20.05.2011 21:44, intrigeri пишет: Near-future plans: investigate and fix abovementioned problems read on .deb packaging (FWIW, we've discussed this privately since.) Also - posted update into project blog section on wiki: https://tails.boum.org/todo/TailsGreeter/blog/ In short - I've managed to build .iso (takes quite some time) and read on .deb and git to get myself up to date with dev environment. read on vala (development environment setup and code samples) Max, how is it going on this side? I'd be glad to have a look at your code samples. They are not mine :) On the positive side - I can read the code, it seems mostly clear and hello world is working as expected. Not much to brag about but every journey starts with a step (or any other philosophical sentence which make it look better :) Normal progress report update into ML will follow within 2 days - got to catch-up and update project's wiki pages. cheers, Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN2a85AAoJEKfeidBDFGO/F4IP/0vsw4wQKBLoUp7oNbf2dAtX mbpMNZFc8togCAOYT5I4GZ3HoLDCZ/y/79Z82LIaA4ltit1KpbfmFO7v6GstizVl jpP/ua3gaPmjRNMFHKw7Bo1WgCfNxNXcSl3/pRBtC+EVCbosPzMD0Eg+6rjUHgkN uJoCClAJpH77EiOybFfgVLlHEDMLboyJfYoXpNKb7JVNakzDaJKK9Z7kego4VZdk dGFe5P41pASKwEvzzUPfNt69p/bWJRuHuwjPGGdqtTIshp/jraya/mxROSnQkU3p dHJZjHmcxFAm01ytQKR5tlP90Hd9lJal5ulBreYbreQZoCW8lSZfyL3g7ENue1xJ URHu/58wUe4L7N6/wQ4Q3xVfZ5Pndi2PoJZgisF4lieaGBh45jjZCdITiZbUsBay VJr/DSmcBzcLOjG1CZL+xcE4ovN3Se1RB3VxUIJXlVGTtD8fgz99jIUWIMmkFPty AhhgxJOceEbnuFZPNJyo/fCgpY1TjBChxO0LbWK0807/+2Zz6cOsKajC2f8S8n4Y QLmES+2GYjCZhzhKGmSEXnToJBM2YSlRcr5cZtIbNNIVu89iIWkPJDQF3civVkhd vun57Ck6QtpRzk1kN47O2GU/u/J67eicn5xe5choMVgG4oMldl8j1uwaDyYJGTXo SFk7v1vFBgZuIDcu6cEm =0EQE -END PGP SIGNATURE- ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
