1. 19 Apr, 2017 1 commit
  2. 18 Apr, 2017 1 commit
  3. 06 Apr, 2017 1 commit
  4. 19 Mar, 2017 2 commits
  5. 02 Mar, 2017 1 commit
  6. 18 Feb, 2017 1 commit
    • anonym's avatar
      Release process: fix url when looking up APT snapshot expiries. · dec93a98
      anonym authored
      * The use of ${RELEASE_BRANCH} worked by coincidence since it can be
        either 'stable' or 'testing', and there happens to also exist Debian
        code names like that, and we set the same expiry for all of
        them. Let's fix on 'stable' which always should exist.
      * The old url was only pointing to the 'debian' archive, and never
        e.g. the 'torproject' one.
      
      Refs: #12171
      dec93a98
  7. 01 Feb, 2017 2 commits
  8. 30 Jan, 2017 1 commit
  9. 24 Jan, 2017 1 commit
  10. 20 Jan, 2017 1 commit
  11. 13 Jan, 2017 2 commits
  12. 12 Jan, 2017 5 commits
  13. 14 Dec, 2016 1 commit
  14. 13 Dec, 2016 2 commits
  15. 12 Dec, 2016 2 commits
  16. 02 Dec, 2016 2 commits
  17. 17 Nov, 2016 2 commits
  18. 16 Nov, 2016 2 commits
  19. 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.
      d1429435
  20. 09 Nov, 2016 1 commit
  21. 03 Oct, 2016 1 commit
  22. 30 Sep, 2016 1 commit
  23. 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
      025d6869
  24. 11 Aug, 2016 1 commit
  25. 10 Aug, 2016 1 commit
  26. 02 Aug, 2016 3 commits