Commit 20885b91 authored by Tails developers's avatar Tails developers

Merge remote-tracking branch 'origin/master' into doc/5636-accessHD

Conflicts:
	wiki/src/doc/encryption_and_privacy/your_data_wont_be_saved_unless_explicitly_asked.mdwn
parents 00f2c60a 60441cc2
......@@ -8,10 +8,9 @@ msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-01-14 16:01+0100\n"
"PO-Revision-Date: 2014-11-10 17:34+0100\n"
"PO-Revision-Date: 2015-01-18 12:44-0000\n"
"Last-Translator: amnesia <amnesia@boum.org>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
......@@ -586,14 +585,12 @@ msgid "Immediately shut down computer"
msgstr "Éteindre immédiatement l'ordinateur"
#: ../config/chroot_local-includes/usr/share/applications/tor-browser.desktop.in.h:1
#, fuzzy
msgid "Tor Browser"
msgstr "Démarre Tor Browser"
msgstr "Démarre le navigateur Tor"
#: ../config/chroot_local-includes/usr/share/applications/tor-browser.desktop.in.h:2
#, fuzzy
msgid "Anonymous Web Browser"
msgstr "Navigateur Web Non-sécurisé"
msgstr "Navigateur Web Anonyme"
#: ../config/chroot_local-includes/usr/share/applications/unsafe-browser.desktop.in.h:2
msgid "Browse the World Wide Web without anonymity"
......
......@@ -372,7 +372,6 @@ msgid "some hints on why [[should you trust Tails|doc/about/trust]],"
msgstr "pourquoi [[faire confiance à Tails ?|doc/about/trust]]"
#. type: Bullet: ' - '
#, fuzzy
#| msgid ""
#| "our [[design document|contribute/design]] about Tails specification, "
#| "threat model and implementation."
......@@ -380,8 +379,8 @@ msgid ""
"our [[design document|contribute/design]] about Tails specification, threat "
"model and implementation,"
msgstr ""
"notre [[page conception|contribute/design]] de Tails, traite des "
"spécifications ainsi que des contenus."
"notre [[page de conception|contribute/design]] à propos de Tails traite des "
"spécifications, modèle de menace et implémentation."
#. type: Bullet: ' - '
msgid ""
......@@ -446,16 +445,16 @@ msgstr ""
"procédure) ont été empruntées à [Liberté Linux](http://dee.su/liberte)."
#. type: Plain text
#, fuzzy, no-wrap
#, no-wrap
#| msgid "<a id=\"tor\"></a>\n"
msgid "<a id=\"related-projects\"></a>\n"
msgstr "<a id=\"tor\"></a>\n"
msgstr "<a id=\"related-projects\"></a>\n"
#. type: Title =
#, fuzzy, no-wrap
#, no-wrap
#| msgid "Related projects\n"
msgid "Similar projects\n"
msgstr "Projets liés\n"
msgstr "Projets similaires\n"
#. type: Plain text
msgid ""
......@@ -471,7 +470,6 @@ msgid "Active projects"
msgstr "Projets actif"
#. type: Bullet: '* '
#, fuzzy
#| msgid "[Odebian](http://www.odebian.org/)"
msgid "[Freepto](http://www.freepto.mx/)"
msgstr "[Freepto](http://www.freepto.mx/)"
......
[[!meta title="Automated builds specification"]]
[[!toc levels=2]]
This blueprints helps to keep track of the discussion on the mailing list, and
is attached to tickets #8655 to specify how to implement #6196 (Build all
This blueprint helps to keep track of the discussion on the mailing list, and
is attached to tickets **#8655** to specify how to implement **#6196** (Build all
active branches).
[[!toc levels=2]]
# Question to discuss
## Which branches we want to build?
We already build the base branches (_stables_, _testing_, _devel_ and
_experimental_ + _feature/jessie_).
We already build the base branches (_stable_, _testing_, _devel_ and
_experimental_) + _feature/jessie_.
The questions raised is mostly concern the _feature/*_ and _bugfix/*_ branches
(so _topic branches_)
The criterias to automatically select the branches to be build could be:
* branches which are not merged to devel||stable||testing, maybe depending on
the targeted release version
* but had new commits since a certain time as in:
- the previous release?
- N weeks time?
- 15 days (arbitrary)?
Some metrics about the number of branches merged per release could give hints
that might help to decide of selection process.
Proposal1:
* branches which are not merged into devel, stable and testing
* but had new commits since the previous release
We should probably also let devs being able to trigger automated builds for a
branch that would not be selected by the previous algo (eg. last commit too
old).
Devs could do so that by dropping a timestamp file in their branch. The
branch would be added to the selection if this timestamp is smaller than a
certain amount of to-be-defined time.
## When to build it
Define the regularity we want to build topic branches, apart from being build
......@@ -40,10 +45,15 @@ at least having an average number of branches per release.
Note that we will have to plug that in automatic tests when they will be
deployed.
Proposal 1: A build a day.
## Notifications
When to notify who? And how to notify them?
Proposal 1: Notify by email the author of the offending commit on failure.
# Scenarios
......@@ -51,8 +61,7 @@ In the folowing scenario:
0. topic branches are named branch T
0. base branches are named branch B
0. Builds are ran on merges which don't raise a conflict, and this is the topic
branch's dev to take care of that.
0. builds are ran on merges which don't raise a conflict. If the merge raises a conflict, then the topic branch's developpes should take care of resolving it.
## Scenario 1 : reviewer
......@@ -66,9 +75,9 @@ In the folowing scenario:
I might want to download the resulting ISO
I might want to get the pkg list
I want the redmine ticket to be notified (optional feature)
Otherwise if it fails I _need_ to see the build logs
And the developer who proposed the merge should be notified
And the ticket shouldn't be reassigned to the branch submitter
Otherwise if it fails the developer who proposed the merge should be notified
And the developper _need_ to see the build logs
And the ticket should be reassigned to the branch submitter
And QA check should be set to `Dev needed`
......@@ -78,15 +87,15 @@ In the folowing scenario:
When I'm working on branch T
Then I need to know if my branch builds after I've pushed
And I need to know if my branch build is broken by something else
possibly weeks after my last commit by e.g Debian changes,
changes in branch B...
possibly weeks after my last commit (by e.g Debian changes,
changes in branch B, ...)
And if the build succeeded
I might want to download the resulting ISO
I might want to get the pkg list
I want the redmine ticket to be notified (optional feature)
Otherwise if it fails I _need_ to see the build logs
And the developer who proposed the merge should be notified
And the ticket shouldn't be reassigned to the branch submitter
And the ticket should be reassigned to the branch submitter
And QA check should be set to `Dev needed`
......@@ -105,7 +114,7 @@ might want to consider it in the future.
## Scenario 1
As a tails developer working on branch B
As a Tails developer working on branch B
When I upload a package to APT suite B
Then I want to know if it broke the build ASAP
......@@ -116,7 +125,7 @@ might want to consider it in the future.
## Scenario 2
As the current RM
When I push new tag T on branch
When I push new tag T on branch B
Then I want the APT suite for tag T to be created
And I want the APT suite B to be copied into the APT suite T
And once this is done, I want a build from the checkout of tag T to be
......@@ -130,3 +139,9 @@ might want to consider it in the future.
When the test suite is ran on the ISO build from my last commit
I want to watch the TV and see the test video in HTML5 from a Torbrowser
## Scenario 4
As a Tails developper
When an ISO is build from my last commit
I want to access it throught remote desktop (VNC/Spice/...) over Tor
......@@ -73,39 +73,40 @@ Grsync is [packaged for debian](https://packages.debian.org/squeeze/grsync).
The documentation for the creation of the encrypted device [[is already written|doc/encryption_and_privacy/encrypted_volumes]].
### Pros
* not that much things to code
* grsync can be easily preconfigurated, eventually with multiple profiles
* this solution separate backup and encryption work
* allows remote backups
### Cons
* seems not really actively developped
* not possible to do incremental backups
* needs a separate encrypted device for backups or reuse the "loopback LUKS"
solution
* does not check if enough space is available on the destination before running
### How to test?
* create an encrypted device.
* install the grsync package.
* paste [those lines](http://dustri.org/p/38e76b) in a .grsync file, then double-click on it.
* paste [those lines](https://paste.debian-facile.org/view/raw/a7a7fe3c) in a `.grsync` file, then double-click on it.
(grsync ask you first to confirm the profile you want to use. Just click on "Open")
* define the destination (i.e your encrypted device)
* test wildly! and please report your results
### Todo
### Pros
* not that much things to code
* grsync can be easily preconfigurated, eventually with multiple profiles
* this solution separates backup and encryption work
* allows remote backups
### Features to request
* grsync should check if enough space is available on the destination before running.
Update: rsync 3.1.0 [introduces](https://rsync.samba.org/ftp/rsync/src/rsync-3.1.0-NEWS) a `--preallocate` option.
(Tails actually ships rsync 3.0.9)
* grsync should ask for confirmation when the option "Delete on the destination" is activated
* when user double-click on a `.grsync` file, a window appears to confirm which file to open. This may be confusing.
### Misc
* some files are normally not readable by rsync (for example persistence.conf, apt/*)
Grsync can bypass that with the option "Run as superuser", we should investigate the consequences of using such an option.
We still have the possibility to ignore those files: we just have then to add `--exclude="apt"` in the preconfiguration file.
* decide if we activate the option `--delete` by default.
* test restoration (see File → Invert source and destination), then at least check files permissions.
* test restoration (see File → Invert source and destination). Then, at least, check files permissions.
* test backup + restoration with symlinks and hardlinks in the Persistent folder.
* eventually test remote backups.
* see the [thread on tails-dev](https://mailman.boum.org/pipermail/tails-dev/2015-January/007931.html)
rdup
----
......
......@@ -23,6 +23,21 @@ Bonus:
* Arch: 1.3.2
* Fedora: 1.3.0 flagged as stable, 1.3.2 in testing
API stability and backwards-compatibility
=========================================
- "all [Docker] containers are backwards compatible, pretty much to
the first version. [...] In general backwards compatibility is a
big deal in the Docker project"
([source](https://news.ycombinator.com/item?id=7985142), shykes
is a Docker developer)
- Apparently the Docker 1.0 release broke older stuff, see e.g. the
0.6 release in
[the jenkins plugin changelog](https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin).
- Environment replacement was formalized in Docker 1.3, and the new
behavior ["will be
preserved"](https://docs.docker.com/reference/builder/#environment-replacement).
Random notes
============
......@@ -47,3 +62,55 @@ Random notes
[[dedicated blueprint|blueprint/Linux_containers]].
* [overclockix](https://github.com/mbentley/overclockix) uses
live-build and provides a Dockerfile for easier building.
* overlayfs support was added in Docker 1.4.0; we'll need that when
using Debian Stretch/sid once Linux 3.18 lands in there after
Jessie is released.
Test run
========
(20150120, Debian sid host, `feature/7530-docker` Git branch)
sudo apt --no-install-recommends install docker.io aufs-tools
sudo adduser "$(whoami)" docker
su - "$(whoami)"
make
* `TAILS_BUILD_OPTIONS="noproxy"` => run [apt-cacher-ng in a different
container](https://docs.docker.com/examples/apt-cacher-ng/)
* Even with `--cache false`, some directories (`chroot`, `cache`) are
saved and retrieved from the container upon shutdown; same for
live-config -generated `config/*` files. That's because the current
directory is shared read-write with the container somehow.
This bind-mount should be read-only, but we still need to get the
build artifacts back on the host:
- see [Managing data in
containers](https://docs.docker.com/userguide/dockervolumes/)
- use `VOLUME` to share (read-write) the place where the build
artifacts shall be copied
* We're currently using the `debian:wheezy` template, that likely we
should not trust. How should we build, maintain, publish and use
our own?
* Being in the `docker` group is basically equivalent to having full
root access. Do we want to encourage contributors to do that, or
to run `docker` commands with `sudo`, or to use Docker in
a virtual machine?
* We currently pass `--privileged` to `docker run`. Should we remove
it, and if yes, how?
- According to
<https://docs.docker.com/articles/dockerfile_best-practices/>,
"many of the “essential” packages from the base images will fail
to upgrade inside an unprivileged container". It seems that
the best practice is to publish _and regularly update_ a base
image, so that the most common usecases can avoid the APT upgrade
steps, and then run unprivileged.
* Adding `.git` to the `.dockerignore` file would speed up the build,
but some code in our build process wants to know what branch or
commit we're building from => maybe we could pre-compute this
information, and pass it to the build command in some way?
* What execution environment do we want to support? Only LXC
via libcontainer? Any usecase for e.g. the systemd- or
libvirt-based ones?
* Move more stuff from `Makefile` to `Dockerfile`? E.g. `DOCKER_MOUNT`
could be specified as `VOLUME`. Can we specify the build command as
`CMD`?
......@@ -15,3 +15,4 @@ Discussions
- [[!tails_ticket 6432 desc="WhisperBack launcher in the applications menu should give a hint about its function"]]
- [[!tails_ticket 7076 desc="Warn against plugging a Tails device in untrusted systems"]]
- [[!tails_ticket 8253 desc="a tool to quickly edit (resize...) pictures"]]
- [[!tails_ticket 8796 desc="Consider using the purple of the logo as background color"]]
......@@ -11,9 +11,10 @@ Goals of our Vagrant thing
2. Improve consistency between our various ways of building Tails ISOs
(Tails developers currently use at least 3 different build setups,
and our auto-builder yet another one).
3. Ideally, our "easy build" instructions should work at least on:
3. Our "easy build" instructions must work at least on:
- Debian stable + backports
- Debian testing
4. Ideally, our "easy build" instructions should also work at least on:
- latest Ubuntu LTS
- latest Ubuntu non-LTS
......@@ -38,7 +39,7 @@ What we have
- retrieve the build artifacts from the build VM onto the host system
* Vagrant hasn't been actively maintained in Debian for a while.
It'll likely be part of Jessie, but that's by a very short margin.
It'll be part of Jessie, but that was by a very short margin.
* VirtualBox vs. QEMU/KVM:
- One can't run both VirtualBox and QEMU/KVM on the same system.
......
[[!toc levels=2]]
Related pages
=============
* [[!tails_ticket 5525]]
* [[blueprint/Mandatory_Access_Control]]
* [[contribute/design/application_isolation]]
Status
======
## automated test passes
(needs to be run again with current status of the branch at some point)
* feature/i2p (unconfined)
* feature/torified_browsing
* feature/unsafe_browser (unconfined)
* feature/windows_camouflage
* open `https://` URL from Pidgin
* relevant bits of feature/usb_install
- view persistent bookmarks, in read-only persistence mode ([[!tails_ticket 8787]])
- persistent bookmarks, RW
## manual test OK
(needs to be tested again with current status of the branch at some point)
* add NoScript exception
* change stuff in about:prefs
* manually update AdBlock Plus lists
* add a bookmark, with persistent bookmarks feature enabled, in
read-only persistence mode
## manual test OK, maybe needs automated test
* download to non-persistent ~/Downloads
* YouTube audio and video playback
* non-YouTube HTML5 video playback
* "Tails documentation" link on the Desktop ([[!tails_ticket 8788]])
## broken
## needs testing
* download to persistent ~/Downloads, in read-write persistence mode
* download to persistent ~/Downloads, in read-only persistence mode
* upload from non-persistent ~/Downloads
* upload from persistent ~/Downloads, in read-write persistence mode
* upload from persistent ~/Downloads, in read-only persistence mode
* import OpenPGP key from website (if supported in 1.2.3)
* click email address on a website (if supported in 1.2.3)
* install a Firefox add-on (this does not mean we actively support that, right? :)
User experience matters
=======================
Downloading files
-----------------
Tor Browser will be allowed to save files in
`/home/amnesia/Downloads/` only.
doc++: where to download, how to upload
Usability issue: if not enough space in RAM for hosting ~/Downloads/
* added a persistence setting for Downloads
* added a GNOME bookmark called "Downloads" when the Downloads
persistence feature is enabled; remaining questions:
- Rename this bookmark "Persistent Downloads"? But then users may
lose data by mistake when they use read-only persistence option.
OTOH, we have had a "Persistent" bookmark for years, even in
read-only persistence mode, and nobody complains.
- Rename this persistent directory and the corresponding bookmark to
include the "Uploading files" use case? (see below)
Uploading files
---------------
Basically the same problem as for downloading files. Is it better to
share a common whitelisted directory, or to add a different one to
the whitelist?
Document that one should put files in the `/home/amnesia/Downloads`
folder before uploading them, and make sure that it's the folder
selected by default when clicking a "Browse" upload button on
a website?
......@@ -18,8 +18,9 @@ How do other live distributions do that?
- http://www.linux-magazine.com/Online/Features/Getting-Started-with-Knoppix-7.3
- Base: Debian
- Desktop: KDE
- Might be interested in our solution.
- [Grml](http://grml.org/)
- Custom script called
- Already have a custom script called
[grml-lock](https://github.com/grml/grml-scripts/blob/master/usr_bin/grml-lock)
which is a wrapper around vlock that asks for a password on first use.
- Base: Debian
......
......@@ -17,13 +17,12 @@ msgstr ""
"X-Generator: Poedit 1.5.4\n"
#. type: Plain text
#, fuzzy, no-wrap
#, no-wrap
#| msgid "[[!meta title=\"bugs\"]]"
msgid "[[!meta title=\"Bugs\"]]\n"
msgstr "[[!meta title=\"bugs\"]]"
msgstr "[[!meta title=\"Bugs\"]]\n"
#. type: Plain text
#, fuzzy
#| msgid ""
#| "If you've found a bug in The Amnesic Incognito Live System, please read "
#| "[[support/found_a_problem]]."
......@@ -31,11 +30,10 @@ msgid ""
"If you've found a bug in Tails, please read [[doc/first_steps/"
"bug_reporting]]."
msgstr ""
"Si vous avez trouvé un bug dans The Amnesic Incognito Live System, veuillez "
"lire la page [[un problème ?|support/found_a_problem]]."
"Si vous avez trouvé un bug dans Tails, veuillez "
"lire la page [[un problème ?|doc/first_steps/bug_reporting]]."
#. type: Plain text
#, fuzzy
#| msgid ""
#| "We don't use this section anymore, see [[!tails_redmine \"\" desc="
#| "\"Redmine\"]] instead."
......@@ -43,5 +41,5 @@ msgid ""
"We don't use this section anymore, see [[contribute/working_together/"
"Redmine]] instead."
msgstr ""
"Nous n'utilisons plus cette section, voir [[!tails_redmine \"\" desc="
"\"Redmine\"]] à la place."
"Nous n'utilisons plus cette section, veuillez plutôt consulter la page "
"relative à [[Redmine|contribute/working_together/Redmine]]."
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-11-30 02:25+0100\n"
"POT-Creation-Date: 2015-01-25 19:23+0100\n"
"PO-Revision-Date: 2014-04-18 23:25+0100\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -465,6 +465,13 @@ msgstr ""
"[[Kalender|contribute/calendar]] der Veröffentlichungen, Treffen, "
"Arbeitsbesprechungen etc."
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Document progress|contribute/working_together/document_progress]]"
msgid "[[Code of conduct|contribute/working_together/code_of_conduct]]"
msgstr ""
"[[Fortschritte dokumentieren|contribute/working_together/document_progress]]"
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Meetings|contribute/meetings]], and minutes from past meetings"
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2014-11-30 02:25+0100\n"
"POT-Creation-Date: 2015-01-25 19:23+0100\n"
"PO-Revision-Date: 2014-03-26 10:50+0100\n"
"Last-Translator: MR\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -437,6 +437,10 @@ msgid ""
"etc."
msgstr ""
#. type: Bullet: ' - '
msgid "[[Code of conduct|contribute/working_together/code_of_conduct]]"
msgstr ""
#. type: Bullet: ' - '
msgid ""
"[[Contributors meetings|contribute/meetings]], and minutes from past meetings"
......
......@@ -164,6 +164,7 @@ Collective process
==================
- [[Calendar|contribute/calendar]] of releases, meetings, working sessions, etc.
- [[Code of conduct|contribute/working_together/code_of_conduct]]
- [[Contributors meetings|contribute/meetings]], and minutes from past meetings
- [[contribute/Low-hanging_fruit_sessions]]
- [[Marking a task as easy|contribute/working_together/criteria_for_easy_tasks]]
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-11-30 02:25+0100\n"
"POT-Creation-Date: 2015-01-25 19:23+0100\n"
"PO-Revision-Date: 2014-05-23 14:56-0300\n"
"Last-Translator: Tails Developers <amnesia@boum.org>\n"
"Language-Team: Portuguese <LL@li.org>\n"
......@@ -468,6 +468,13 @@ msgstr ""
"[[Calendário|contribute/calendar]] de lançamentos, reuniões, sessões de "
"trabalho, etc."
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Document progress|contribute/working_together/document_progress]]"
msgid "[[Code of conduct|contribute/working_together/code_of_conduct]]"
msgstr ""
"[[Documentação de progresso|contribute/working_together/document_progress]]"
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Meetings|contribute/meetings]], and minutes from past meetings"
......
......@@ -2,6 +2,13 @@
[[!toc levels=2]]
Git repository and branches
===========================
You will need to clone the Tails Git repository, and to checkout the
branch that you want to build (most likely, _not_ `master`): learn
more about [[our Git branches layout|contribute/git#main-repo]].
<a id="vagrant"></a>
Using Vagrant
......
......@@ -2,9 +2,28 @@
* 2015-02-03: [[Monthly meeting|contribute/meetings]]
* 2015-03-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]