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

po/fr.po

@@ -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"

wiki/src/about.fr.po

@@ -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/)"

wiki/src/blueprint/automated_builds_and_tests/autobuild_specs.mdwn

 [[!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

wiki/src/blueprint/backups.mdwn

@@ -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
 ----

wiki/src/blueprint/evaluate_Docker.mdwn

@@ -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`?

wiki/src/blueprint/monthly_meeting.mdwn

@@ -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"]]

wiki/src/blueprint/replace_vagrant.mdwn

@@ -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.

wiki/src/blueprint/sandbox_the_web_browser.mdwn

+[[!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?

wiki/src/blueprint/screen_locker.mdwn

@@ -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

wiki/src/bugs.fr.po

@@ -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]]."

wiki/src/contribute.de.po

@@ -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"

wiki/src/contribute.fr.po

@@ -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"

wiki/src/contribute.mdwn

@@ -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]]

wiki/src/contribute.pt.po

@@ -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"

wiki/src/contribute/build.mdwn

@@ -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

wiki/src/contribute/calendar.mdwn

@@ -2,9 +2,28 @@
 
 * 2015-02-03: [[Monthly meeting|contribute/meetings]]
 
-* 2015-03-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]