Commit a4ebac59 authored by Ulrike Uhlig's avatar Ulrike Uhlig

Merge branch 'master' of d53ykjpeekuikgoq.onion:tails

parents 63a16e9a 6ec6253a
http://torbrowser-archive.tails.boum.org/8.0.7-build3/
http://torbrowser-archive.tails.boum.org/8.0.8-build1/
ca18208ec388ede9dca348d94cd4805c605b7fbe8ff09a6f09346f4f36b587d4 tor-browser-linux64-8.0.7_ar.tar.xz
38ce192c9c608d123c490e25d18081c4b79517055e1359f24a09221cb318e340 tor-browser-linux64-8.0.7_ca.tar.xz
387d13665f96cf84742afa90e37589f424bcb211b650dc5f2d5983a0cf39204b tor-browser-linux64-8.0.7_da.tar.xz
aae6170a5629a26b48c054a6005b66544e67d59e1755aea19a5db7d3b5cc4ed9 tor-browser-linux64-8.0.7_de.tar.xz
bebe0f457f26723687073704ab4b072b696928dccdc1c73ff42d22f2688432e7 tor-browser-linux64-8.0.7_en-US.tar.xz
599e689bf94b9dc139444a4a81756cac05c25722c8ca5607d496063d02f19cf5 tor-browser-linux64-8.0.7_es-ES.tar.xz
70cf462e9b47f9df4d5bd1488820b4baaf5d60953a6f5ecaad5be290e3c0be77 tor-browser-linux64-8.0.7_fa.tar.xz
a6ff3036fa5d72ce6e63b751df28fa6342adfd98199ff9d2971881c8e8702d7b tor-browser-linux64-8.0.7_fr.tar.xz
88154a65257662cdf808073e5060459eac4f8f4354fb8a3c23c491e63e3971e5 tor-browser-linux64-8.0.7_ga-IE.tar.xz
edc358fa2992c4c1b7c9eaae21d9af23dfd7905925994782b305aba6c2e4e24d tor-browser-linux64-8.0.7_he.tar.xz
f3576c3987e178a0f6f86e69b57c3af0664b29e1b2eb0fe13fbaec65c85eb3f9 tor-browser-linux64-8.0.7_id.tar.xz
7a336b903e25e901b98d0c69cddec002d1a30130586542190890a17841e4df12 tor-browser-linux64-8.0.7_is.tar.xz
0a7534e676724799fdd3d460e8dc3fb9058c3b22c35f062ea573524873f38de3 tor-browser-linux64-8.0.7_it.tar.xz
6b100256672a51bc67b3c1163d42a3891c17d3bcb601d306d3439a6331bcdaa1 tor-browser-linux64-8.0.7_ja.tar.xz
928b9f835838bce822e07adfe40fb88811db68e6b020c9b58e1d55fa386f9a35 tor-browser-linux64-8.0.7_ko.tar.xz
7fd87d8e173cb8a9473a143e47c88096d69266b514c2dfc07dcc8bab4fb2d16d tor-browser-linux64-8.0.7_nb-NO.tar.xz
db55ea1acd9d7d39903c092241049d4bd5de138bd939d786844a1eda34b582c4 tor-browser-linux64-8.0.7_nl.tar.xz
e66d1c534b038a4bfe1dc7bff88a8a17bd6734f391187d926cbe0fcf3cb9b05a tor-browser-linux64-8.0.7_pl.tar.xz
3a51f831e6c0fc89fa33ea463920c974bf694da8aa0ec02201d9d8a01b51e26c tor-browser-linux64-8.0.7_pt-BR.tar.xz
843e9c3c67bc623cb0d0470fa88dbbe2c67460de641bebbd641f4e727a64eb67 tor-browser-linux64-8.0.7_ru.tar.xz
636c9cb14f632a03f073adef207b030f11c34e5f4254f756b95acd318defb38b tor-browser-linux64-8.0.7_sv-SE.tar.xz
a84f3710d293a240235460132b24f9bd514ccc9f483dd101c1258404357dc5fd tor-browser-linux64-8.0.7_tr.tar.xz
36c34cf23fd137c2bf445529cdfa5a7b2ed98873313c6f9e26342922b8b3b53d tor-browser-linux64-8.0.7_vi.tar.xz
ad5c782529f746050455916612a30b39c3acd0f77dace259401ed585f588f8d2 tor-browser-linux64-8.0.7_zh-CN.tar.xz
ba5a00e4bfe40de90c3c2be170367abaa45b86df0fab88cb966ba3bc37efe070 tor-browser-linux64-8.0.7_zh-TW.tar.xz
827381c6265029e90bbe0510a3805ded275fa43a6c1e9a70ad6b573954cf8b07 tor-browser-linux64-8.0.8_ar.tar.xz
a22fdb04003f0101915bfecd00326b11e5114041c1447b25d5691ec4db940c64 tor-browser-linux64-8.0.8_ca.tar.xz
a482769c70e35206b9a82f0ac03b3c24d741055d6e3bb8af19cf80168e4fd043 tor-browser-linux64-8.0.8_da.tar.xz
13f6d439dbc1c612bc2a03849b0fcc0e861629b33ccf4bbdcc8a8d2fb32716c1 tor-browser-linux64-8.0.8_de.tar.xz
b16b80a858dd28f254b2f748324b632fef7ebe8331a2d46c67016c1f1d5c9391 tor-browser-linux64-8.0.8_en-US.tar.xz
1d736ab404b1080d7820195230534f1e4ea802b4f8d114c02c1b614df5e1fab2 tor-browser-linux64-8.0.8_es-ES.tar.xz
a3136cbf990476114ae74f16d42c2a159f18032e94f172bdef75f9af7ffba8cf tor-browser-linux64-8.0.8_fa.tar.xz
0f90c194b30ad354f28cdb1993206ba45c8fdd6a3c698bb349a84efb07053bf9 tor-browser-linux64-8.0.8_fr.tar.xz
0322b4f824acfbb9b9b12aa466ffaedafe452c6e047d2023ec30d178676c02eb tor-browser-linux64-8.0.8_ga-IE.tar.xz
5cbe242b770d6c7ac7a8ed6139ebcb8fb1467a79d5f4910b0022044b71fa9f36 tor-browser-linux64-8.0.8_he.tar.xz
7774cd4c54ea64376a1dd126399784e8a5b466fa054851a554a1c2e8de731c02 tor-browser-linux64-8.0.8_id.tar.xz
6ecbea10450e57255e9a94a150b61e2fd7d70d225f52be4c117bdd1d2e3c6052 tor-browser-linux64-8.0.8_is.tar.xz
a9027f09b3c251bc7a80b90071f2b96860e9acdff773cf31f275e760ab17006d tor-browser-linux64-8.0.8_it.tar.xz
bebffb31e66fee4bd7b84af9863fbf23990d3c88021703fcedd1ad38e203b348 tor-browser-linux64-8.0.8_ja.tar.xz
c746ad231274011adb909c6b168ff4007d4964d8eec1ef23d2310f4b5996f207 tor-browser-linux64-8.0.8_ko.tar.xz
d6a160ebe8fa448d768022b02c7a8bbfdc5de55787fd3eab99adf275dd79c9ff tor-browser-linux64-8.0.8_nb-NO.tar.xz
93a306495215e8c2f70dd2d06ff09197c88926e4ac3a043ca1253a8999c0ffb0 tor-browser-linux64-8.0.8_nl.tar.xz
8ffef293214e770f96907429145bb7daa2cb01e0a4b14c67e58f5e072d268fb5 tor-browser-linux64-8.0.8_pl.tar.xz
3a3816c9069983576b4d1c3f8371315f89a55a7f37a00af572b3e790208c47a4 tor-browser-linux64-8.0.8_pt-BR.tar.xz
a0fa85ea83c65bb999c5351c59c97f6f40af933b51fde5b882ef9e264ed322c5 tor-browser-linux64-8.0.8_ru.tar.xz
d27af9f27823a4a9a93d762eea036e104af599a642af99aa962dc31f2a7b308f tor-browser-linux64-8.0.8_sv-SE.tar.xz
f32c98481fff6cdbed9db9ad623532f4c2a1417399c1da852b92e301b78efb0e tor-browser-linux64-8.0.8_tr.tar.xz
a7a64668a3cc083f517df75636594baded35d590716a417af295b2a8b147fab2 tor-browser-linux64-8.0.8_vi.tar.xz
fa5e6e8d1dfe580a639463a2240286b110eb8f1684ade467d2e8ca384746a70e tor-browser-linux64-8.0.8_zh-CN.tar.xz
d28190b1a802b1e75105302866c4b2d8d03eed9c9c4c93b85ac5fe63e06782d7 tor-browser-linux64-8.0.8_zh-TW.tar.xz
tails (3.13.1) unstable; urgency=medium
* Security fixes
- Upgrade Tor Browser to 8.0.8 (Closes: #16606, MFSA-2019-10).
- Upgrade NTFS-3G to 1:2016.2.22AR.1+dfsg-1+deb9u1 (DSA-4413-1).
-- Tails developers <tails@boum.org> Fri, 22 Mar 2019 20:54:03 +0000
tails (3.13) unstable; urgency=medium
* Major changes
......
......@@ -11,7 +11,13 @@ enabled, without the user having to do _anything_ special about it.
Means: use the shim signed by Microsoft + GRUB2.
We don't support booting on a custom built kernel, so that should be
relatively easy.
relatively easy. Except:
* The kernel won't allow loading an unsigned `aufs` module so we need
to migrate to `overlayfs` ([[!tails_ticket 8415]]).
* `overlayfs` does not allow stacking enough layers for our current
upgrade system, so we need to [[!tails_ticket 15281 desc="stack one
single SquashFS diff when upgrading"]].
Resources
=========
......
......@@ -28,6 +28,19 @@ XXX: If you feel like it and developers, foundation team, and RMs don't do it th
Release section (for example, the changes being worked on for
the next version).
- Two Tails developers attended a Debian Bug Squashing Party
in Paris.
- We discussed our policy regarding languages support and started
implementing the agreement we've reached ([[!tails_ticket 15807]],
[[!tails_ticket 16094]], [[!tails_ticket 9956]]).
- We identified another possible cause for partially applied
automatic upgrades ([[!tails_ticket 16603]]).
- We coordinated with the Tor Browser team wrt. their upcoming 8.5
major release and its implications for Tails.
Documentation and website
=========================
......@@ -57,6 +70,19 @@ XXX: Ask tails-bugs@boum.org to list hot topics for the last month.
Infrastructure
==============
- We started making plans to migrate to GitLab.
- We interviewed 2 candidates for our open sysadmin position.
- We made good progress on switching to better maintained Puppet
modules ([[!tails_ticket 15510]]).
- We worked on the software configuration of the prototype node for
our next-generation CI hardware ([[!tails_ticket 15501]]).
- We fixed our LimeSurvey security updates monitoring system
([[!tails_ticket 15466]]).
Funding
=======
......@@ -91,13 +117,6 @@ On-going discussions
XXX: Link to the thread on <https://lists.autistici.org/list/tails-XXX.html>.
Press and testimonials
======================
XXX: Copy content from press/media_appearances_2019.mdwn
This page is continuously updated by tails-press@boum.org, so if
it's empty there might be nothing special to report.
Translations
============
......@@ -111,8 +130,8 @@ XXX: Add the output of (adjust month!):
Metrics
=======
* Tails has been started more than BOOTS/MONTH times this month. This makes BOOTS/DAY boots a day on average.
* SIGS downloads of the OpenPGP signature of a Tails USB image or ISO from our website.
* Tails has been started more than 809 770 times in March. This makes 26 121 boots a day on average.
* 9 970 downloads of the OpenPGP signature of a Tails USB image or ISO from our website.
* WHISPERBACK bug reports were received through WhisperBack.
[[How do we know this?|support/faq#boot_statistics]]
......
* This suppose you have either a sid/experimental system with latest GNOME packages or a pbuilder experimental setup.
* In a VM, enable experimental sources then:
apt-get build-dep -t experimental gnome-shell
apt-get install quilt git-buildpackage
* For pbuilder:
pbuilder create --distribution experimental --override-config
* clone debian git in gnome-shell-debian
git clone https://salsa.debian.org/gnome-team/gnome-shell.git gnome-shell-debian
* create upstream/latest branch
git co -b upstream/latest origin/upstream/latest
* clone upstream git
git clone https://gitlab.gnome.org/GNOME/gnome-shell.git gnome-shell-git
git submodule update --init
* disable upstream VCS tag checking
commit 3f53de522495a321bb962e5b9e4ddaca66957823
Author: user <user@debian>
Date: Tue Apr 2 16:31:22 2019 +0200
disable upstream VCS tag checking
diff --git a/debian/gbp.conf b/debian/gbp.conf
index b24011a15..904e0e5d0 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -2,7 +2,7 @@
pristine-tar = True
debian-branch = debian/master
upstream-branch = upstream/latest
-upstream-vcs-tag = %(version)s
+#upstream-vcs-tag = %(version)s
[buildpackage]
sign-tags = True
* import upstream repository
gbp import-orig --verbose --upstream-version=3.33.0-4 --filter=.git --filter=.gitignore ~/Documents/gnome-shell-git/
^
increase this at each build
* disable all patches
commit 31962cfec99808e57404a970c59202c8e40c1c76 (HEAD -> debian/master)
Author: user <user@debian>
Date: Tue Apr 2 16:38:27 2019 +0200
disable all debian specific patches
diff --git a/debian/patches/series b/debian/patches/series
index 2e1f1ebb9..e69de29bb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,8 +0,0 @@
-userWidget-Fix-avatar-size.patch
-layout-Use-custom-actor-for-uiGroup.patch
-texture-cache-Apply-resource-scale-to-the-right-dimension.patch
-theme-improve-legibility-of-error-messages.patch
-st-widget-Add-missing-g_return_val_if_fail.patch
-st-theme-node-transition-Exclude-get_new_paint_state-from.patch
-magnifier-Fix-color-argument.patch
-tweener-Save-handlers-on-target-and-remove-them-on-destro.patch
* build
gbp buildpackage
or with pbuilder:
BUILDER=pbuilder gbp buildpackage --git-pbuilder --git-dist=experimental --git-arch=amd64 -nc
* install
sudo dpkg -i ../gnome-shell_3.33.0-4-1_amd64.deb ../gnome-shell-common_3.33.0-4-1_all.deb
......@@ -209,29 +209,39 @@ When a Git *main* branch (`devel`, `testing`, `stable`,
`feature/jessie`) is merged into another *main* branch, the corresponding
operation must be done on the APT suites.
0. Set some environment variables:
WORKDIR=$(mktemp -d)
# the branch you want to merge
SRC=stable
# the branch you want to merge _into_
DST=devel
1. Save the list of packages currently present in the APT suite we
want to merge *into*, e.g. `reprepro list devel`.
want to merge *into*:
ssh reprepro@incoming.deb.tails.boum.org \
reprepro list "$DST" \
> "$WORKDIR/$DST.orig.list"
2. Make sure you are not going to overwrite newer packages with
older ones (hint: use the `tails-diff-suites` script).
older ones:
3. Merge the APT suites:
ssh reprepro@incoming.deb.tails.boum.org \
tails-diff-suites "$SRC" "$DST"
1. Set some environment variables:
… and look for packages that are newer in `$DST` than in `$SRC`.
# the branch you want to merge
SRC=stable
# the branch you want to merge _into_
DST=devel
3. Merge the APT suites:
2. Merge in Git and APT:
1. Merge in Git and APT:
git checkout "$DST" && \
git merge "$SRC" && \
ssh reprepro@incoming.deb.tails.boum.org \
tails-merge-suite "$SRC" "$DST"
3. Restore the `config/base_branch` if needed:
2. Restore the `config/base_branch` if needed:
echo "${DST}" > config/base_branch && \
git commit config/base_branch -m "Restore ${DST}'s base branch." || :
......
......@@ -4,9 +4,9 @@ All times are referenced to Berlin and Paris time.
## 2019Q1
* 2019-03-19: Test and **release Tails 3.13** (kibi is the RM)
* 2019-03-23: Build and upload **release Tails 3.13.1** (intrigeri is the RM)
* 2019-03-20 to 2019-03-22: [[!wikipedia Pwn2Own]], which often triggers an emergency Firefox release
* 2019-03-24: Test and **release Tails 3.13.1** (Firefox 60.6.1, Tor Browser 8.0.8; bugfix release — intrigeri is the RM; XXX is the TR)
* 2019-04-02 to 2019-04-05: [[Foundations Team|contribute/working_together/roles/foundations_team]] sprint
- Port Tails to Debian 10 (Buster)
......@@ -32,7 +32,9 @@ All times are referenced to Berlin and Paris time.
* 2019-10-03, 16:00: [[Foundations Team|contribute/working_together/roles/foundations_team]] meeting
* 2019-10-22: **Release 3.17 or 4.0** (Firefox 68.2, major release)
* 2019-10-22: **Release 3.17** (Firefox 68.2, major release); this release might be
based on Debian Buster and then called 4.0, but for now Release Managers
should assume it's 3.17
* 2019-11-06, 16:00: [[Foundations Team|contribute/working_together/roles/foundations_team]] meeting
......
......@@ -134,7 +134,7 @@ before being merged, it's better if you push your work to a dedicated
Git topic branch, and [[ask us to review it|contribute/merge policy/submit]]. If you already know where
to host your personal repository in a public online place, this is
great; otherwise, you can [fork us on
GitLab](https://gitlab.com/Tails/tails), or ask the Tails system
Salsa](https://salsa.debian.org/tails-team/tails), or ask the Tails system
administrators ([[tails-sysadmins@boum.org|about/contact#tails-sysadmins]]) to host your repository.
# Want more?
......
......@@ -27,8 +27,8 @@ Resources
- [[Paper prototyping and *WireframeSketcher*|user_experience/paper_prototyping]]
- [[Survey platform (*LimeSurvey*)|user_experience/limesurvey]]
- [[Guidelines for user testing|user_experience/testing]]
- [[Recording user testing|user_experience/recording]]
- [[Guidelines for usability testing|user_experience/testing]]
- [[Recording usability testing|user_experience/recording]]
- [[Preparing video clips|user_experience/clip]]
- Participant Bill of Rights (adapted from
[Simply Secure](https://simplysecure.org/knowledge-base/)):
......@@ -37,7 +37,7 @@ Resources
- System Usability Scale (SUS) questionnaire:
- [English ODT](https://github.com/sajolida/tails-ux/raw/master/tools/SUS.en.fodt)
- [Spanish ODT](https://github.com/sajolida/tails-ux/raw/master/tools/SUS.es.fodt)
- Checklist for user testing:
- Checklist for usability testing:
- [English ODT](https://github.com/sajolida/tails-ux/raw/master/tools/user_testing_checklist.fodt)
- Rainbow table:
- [Template ODS](https://github.com/sajolida/tails-ux/raw/master/tools/rainbow_table.fods)
......
[[!meta title="Recording user testing"]]
[[!meta title="Recording usability testing"]]
[[!toc levels=2]]
......
[[!meta title="Guidelines for user testing"]]
[[!meta title="Guidelines for usability testing"]]
User testing is an irreplaceable tool to understand user experience and
Usability testing is an irreplaceable tool to understand user experience and
take decisions while doing design iterations. Here are a few guidelines
to take the most of it.
......
......@@ -24,6 +24,10 @@
maintenance includes: polishing the proposed changes to make them fit
for release; writing and updating the design and end-user
documentations; fixing bugs.
- As reviewer, you are allowed to commit trivial fixes on top of the
proposed branch to avoid round-trips: for example, fixing typos
and improving phrasing of comments and strings.
Then, report back about these changes on the ticket.
- Remember that it's hard to receive negative feedback. Don't forget
to note the good parts, be constructive and precise in your
comments, and never use reviews to make personal attacks. You can
......@@ -33,6 +37,14 @@
## Merge
<div class="note">
If the proposed change was submitted as a merge request on <a
href="https://salsa.debian.org/tails-team/tails">Salsa</a>, don't
click <i>Merge</i> there: while we can use GitLab for reviews, our
infrastructure is not ready to consume merge operations done there, so
you need to merge on the command line.
</div>
Merge the branch with `--no-ff`:
- for a new feature: into `devel`
......
......@@ -5,30 +5,36 @@ be named `feature/XXX`. For a bugfix about YYY, it should be named
`bugfix/YYY`. Ideally, include the relevant ticket number in the topic
branch name, e.g. `bugfix/7173-upgrade-syslinux`.
When the developer thinks it is good enough and has tested it, she must:
When you think it is good enough and have tested it, you have to:
- Set the ticket's *Status* field to *In Progress* (if you do not see
this field when editing the ticket, ask the [[sysadmin team|contribute/working_together/roles/sysadmins]]
to grant you the necessary permissions).
- Point the ticket's *Feature Branch* field to your branch.
- Set the ticket's *Target version* field to the release you would
like your changes to be in.
- If you have access to our Jenkins instance (if you don't know what
this means, you do not) please make sure that your branch has not
broken any tests! Or, if you only want a first review of your code,
without bothering with the build & test status on Jenkins, that's fine:
make it clear to the reviewer that it's what you expect and that
your branch is not ready to merge.
- Set the ticket's *QA Check* field to *Ready for QA*.
- Assign this ticket to nobody (aka. unassign it from yourself) by
default. Unless it's clear to you that nobody on the
[[Foundations Team|working_together/roles/foundations_team]] will be
able or willing to do this specific review; in that case, _you_ shall try
to find someone else to do the review, and assign the ticket
to them.
- For important changes, if you feel the need to ask input from the
greater development community, notify the [[tails-dev@boum.org|about/contact#tails-dev]]
mailing list.
1. Push your branch
- If you have commit access to the official Tails Git repository,
push your branch there so our CI picks it up.
- Else, push to your personal Git repository:
[fork us on Salsa](https://salsa.debian.org/tails-team/tails).
2. Set the ticket's *Status* field to *In Progress* (if you do not see
this field when editing the ticket, ask the [[sysadmin team|contribute/working_together/roles/sysadmins]]
to grant you the necessary permissions).
3. Point the ticket's *Feature Branch* field either to your branch
or to a merge request on [Salsa](https://salsa.debian.org/tails-team/tails).
4. Set the ticket's *Target version* field to the release you would
like your changes to be in.
5. If you have access to our Jenkins instance (if you don't know what
this means, you do not) please make sure that your branch has not
broken any tests! Or, if you only want a first review of your code,
without bothering with the build & test status on Jenkins, that's fine:
make it clear to the reviewer what you expect and
that your branch is not ready to merge.
6. Set the ticket's *QA Check* field to *Ready for QA*.
7. Assign the ticket to nobody (aka. unassign it from yourself) by
default. Unless it's clear to you that nobody on the
[[Foundations Team|working_together/roles/foundations_team]] will be
able or willing to do this specific review; in that case, _you_ shall try
to find someone else to do the review, and assign the ticket
to them.
8. For important changes, if you feel the need to ask input from the
greater development community, notify the [[tails-dev@boum.org|about/contact#tails-dev]]
mailing list.
Then, if the [[reviewer|contribute/merge_policy/review]] asks for more
development to be done before
......@@ -37,3 +43,8 @@ more dev* or *Needs more info* state, and
from now on it's the responsibility of the branch/ticket "holder" to
change it back to *Ready for QA* once they consider the issues raised by
the reviewer are fixed.
The reviewer is allowed to commit trivial fixes on top of the
proposed branch to avoid round-trips: for example, fixing typos
and improving phrasing of comments and strings. They must
report back about these changes on the ticket.
......@@ -27,8 +27,33 @@ To release Tails you'll need some packages installed:
Environment
===========
Export the following environment variables to be able to copy'n'paste
the scripts snippets found on this page:
To be able to copy'n'paste the code snippets found on this page,
you need to set a bunch of environment variables.
Unless the release process explicitly instructs you to change the
value of one such variable, treat it as a constant: else,
inconsistency will surely arise, which can cause trouble later on.
Version numbers
---------------
Note:
* Regarding version numbers, what follows supports just fine the case
when we do something else than alternating bugfix and major releases
consistently. For example, if the next two releases are bugfix ones,
do not set `$NEXT_PLANNED_MAJOR_VERSION` to one of these
bugfix releases. Instead, set it to the version number of the next
major release.
* The `$NEXT*VERSION` constants are used only for two types of
operations: preparing upgrade-description files and adding changelog
entries. This two types of operations have to be consistent with
each other: for example, if one adds a dummy entry for version X in
a changelog, an UDF must exist for version X as well… hence the use
of shared constants to encode the values that must be the same on
both sides :)
Export the following environment variables:
* version numbers (see [[contribute/release_schedule#versioning]]):
......@@ -41,7 +66,8 @@ the scripts snippets found on this page:
*major* Tails release; if you're preparing a RC for a major release,
use that major release; otherwise, use whatever the next planned
major release is
* `SECOND_NEXT_PLANNED_MAJOR_VERSION`: set to the version number of
* `SECOND_NEXT_PLANNED_MAJOR_VERSION`: if you're preparing the RC
for a major release, set this to the version number of
the second next *major* Tails release; e.g. if preparing the RC for
the 3.9 major release, then set this to 3.12 (3.9 is the next major
release, 3.10 and 3.11 are bugfix releases, 3.12 is a major
......@@ -51,6 +77,12 @@ the scripts snippets found on this page:
that one; otherwise, use `${VERSION}.1`
* `NEXT_POTENTIAL_EMERGENCY_VERSION`: set to the version number we'll give
to the next emergency release if we have to put one out
Other variables
---------------
Also export the following environment variables:
* `MAJOR_RELEASE`: set to 1 if preparing a major release or a release
candidate for a major release, to 0 otherwise
* `ISOS`: the directory where one stores `tails-amd64-*`
......@@ -604,11 +636,8 @@ suite should be ready, so it is time to:
echo "https://jenkins.tails.boum.org/job/build_Tails_ISO_${RELEASE_BRANCH}/"
Find the job (probably the last one)
and make sure the ISO and USB images built by Jenkins:
- were built from the correct Git commit
- have the same file size as the images you built
- have the same hash (in the `.shasum` file) as the images you built
and make sure the ISO and USB images built by Jenkins
have the same hash (in the `.shasum` file) as the images you built.
Then:
......@@ -858,7 +887,7 @@ Prepare upgrade-description files
fi
) \
$( \
for version in ${IUK_SOURCE_VERSIONS:?}; do
for version in $(echo ${IUK_SOURCE_VERSIONS:?}); do
echo "--previous-version ${version:?}"
done \
) \
......@@ -1044,6 +1073,8 @@ candidate):
## Announce, seed and test the Torrent
Skip this section if [[!tails_ticket 16378]] is not resolved yet.
Check if there's enough space on our Bittorrent seed to import the new
ISO and USB images:
......@@ -1131,6 +1162,8 @@ Testing
1. Triage test results, reproduce bugs as needed, decide what the next
step is and make sure it happens: add to known issues? file ticket?
release blocker? improve the test description (steps, expected outcome)?
1. If [[!tails_ticket 16378]] is not resolved yet, ensure someone will
seed the Torrent.
Update the website and Git repository
=====================================
......@@ -1170,6 +1203,12 @@ Rename, copy, garbage collect and update various files:
sed 's/ /\&nbsp;/g;s/</\&lt;/;s/>/\&gt;/;s/$/<br\/>/g' > \
"${RELEASE_CHECKOUT:?}/wiki/src/inc/stable_amd64_img_gpg_signature_output.html"
Then, build the website and commit this last set of changes:
./build-website && \
git add wiki/src && \
git commit -m "Update various website source files for ${VERSION:?}"
Ensure our [[contribute/working_together/roles/technical_writer]] has
[[written|contribute/how/documentation/release_notes]] the
announcement for the release in `wiki/src/news/version_${TAG:?}.mdwn`.
......@@ -1441,7 +1480,7 @@ this, and skip what does not make sense for a RC.
1. If you just released a new stable release, remove the previous
stable release from:
- our rsync server:
`ssh rsync.lizard rm -rf /srv/rsync/tails/tails/stable/tails-amd64-${PREVIOUS_VERSION:?}/`
`ssh rsync.lizard sudo rm -rf /srv/rsync/tails/tails/stable/tails-amd64-${PREVIOUS_VERSION:?}/`
- our Bittorrent seed: get the previous release's _Transmission_ IDs
(ISO and USB image)
with `ssh bittorrent.lizard transmission-remote --list` and then
......@@ -1464,7 +1503,7 @@ this, and skip what does not make sense for a RC.
- then actually delete the files:
ssh rsync.lizard /bin/sh -c \
\"find /srv/rsync/tails/tails/alpha \
\"sudo find /srv/rsync/tails/tails/alpha \
/srv/rsync/tails/tails/stable \
-type f -name '*.iuk' -mtime '+270' \
-not -name '*~test_*~test.iuk' -delete \
......@@ -1510,11 +1549,6 @@ this, and skip what does not make sense for a RC.
APT repository documentation. This includes some git operations,
like creating an appropriate _"dummy changelog entry"_ in the
`debian/changelog` file.
1. Make sure there are upgrade-description files for any new versions
that were added in the `debian/changelog` file since the last
release. Background: From time to time the UDF generation/update
step isn't perfect and entries might be missing from
`wiki/src/upgrade/v1/Tails/<VERSION>/<ARCH>/<CHANNEL>`.
1. Verify that the snapshots used in the release branch are ok,
e.g. they use the correct snapshots, and they were bumped
appropriately (they should expire after the next planned major release date).
......
......@@ -157,27 +157,19 @@ tracked by tickets prefixed with `todo/test_suite:`.
# Thunderbird
* Check mail over IMAP using:
- a hidden service IMAP server (e.g. Riseup, zsolxunfmbfuq7wf.onion on port 993 with SSL).
- a hidden service IMAP server (e.g. Riseup, 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd.onion on port 993 with SSL).
* Check mail over POP using:
- a hidden service POP server (see above, on port 995 with SSL).
* Send an email using:
- a hidden service SMTP server (see above, on port 465 with SSL).
* Check that the profile works and is torified:
1. Send an email using Thunderbird and a non-anonymizing SMTP relay (a
SMTP relay that writes the IP address of the c