1. 12 Jan, 2017 3 commits
  2. 14 Dec, 2016 1 commit
  3. 13 Dec, 2016 2 commits
  4. 12 Dec, 2016 2 commits
  5. 02 Dec, 2016 2 commits
  6. 17 Nov, 2016 2 commits
  7. 16 Nov, 2016 2 commits
  8. 10 Nov, 2016 1 commit
    • anonym's avatar
      Let's only force new releases of bundled .deb:s for each major release. · d1429435
      anonym authored
      Rationale: the translation work is not moving very fast these days,
      being quite polished for many languages, so we gain very little from
      frequently pulling it and preparing releases *only* for new translations
      (no new code). So, let's relieve the RM from this work for most
      releases, but still have a process in place for making sure that
      translations are pulled regularly.
  9. 09 Nov, 2016 1 commit
  10. 03 Oct, 2016 1 commit
  11. 30 Sep, 2016 1 commit
  12. 28 Aug, 2016 1 commit
    • intrigeri's avatar
      Never (pretend to) thaw APT snapshots on the stable branch. · 025d6869
      intrigeri authored
      Let's always encode, on the stable branch, the exact set of APT snapshots we
      want to use in next point-release. Previously we would pretend to thaw them by
      writing "latest" in APT_snapshots.d/*/serial, but then apt-mirror would
      special-case this situation: on an unreleased branch based on stable, it would
      consider that "latest" means "stick to previous release's tagged snapshot".
      Which worked fine at build time, except the part of our build system that
      creates the build manifest does not know about this convention, so the resulting
      build manifest would point to the latest APT snapshots we have, even though they
      were not really used during the build. And even if the build manifest pointed to
      the right place (i.e. the previous release's tagged APT snapshot), which is the
      only place where some of the needed packages are when tagging the next
      point-release's APT snapshot: tails-prepare-tagged-apt-snapshot-import does not
      know how to generate a configuration that pulls from there.
      So let's drop this special meaning of "latest", and make things simpler by
      actually hard-coding in Git the snapshots we really want to use.
      This implies the documentation change that makes sure that we're keeping these
      time-based APT snapshots long enough.
      refs: #11612
  13. 11 Aug, 2016 1 commit
  14. 10 Aug, 2016 1 commit
  15. 02 Aug, 2016 3 commits
  16. 01 Aug, 2016 6 commits
  17. 31 Jul, 2016 5 commits
  18. 08 Jun, 2016 2 commits
  19. 06 Jun, 2016 3 commits