1. 10 Aug, 2019 1 commit
  2. 11 Jul, 2019 2 commits
  3. 05 Oct, 2017 1 commit
    • anonym's avatar
      Rebase Tails on Debian Buster. · 2f106487
      anonym authored
      And so our experiment to evaluate whether Tails should be based on
      Debian testing begins!
      
      Note that for now we won't treat it as a base branch, and just base it
      on devel. This way we don't have to keep the devel and feature-buster
      APT suite synced, and instead we can use feature-buster only for the
      things deviating from devel.
      
      Refs: #14578
      2f106487
  4. 26 May, 2017 1 commit
  5. 10 May, 2017 2 commits
  6. 09 May, 2017 1 commit
  7. 18 Apr, 2017 2 commits
  8. 17 Mar, 2017 2 commits
  9. 15 Mar, 2017 1 commit
  10. 08 Mar, 2017 1 commit
  11. 28 Aug, 2016 4 commits
    • intrigeri's avatar
      99a5f8de
    • intrigeri's avatar
      Simplify freezable APT repository handling for stable and testing -based branches. · aed83f94
      intrigeri authored
      We now enforce that any branch based on stable or testing uses frozen
      APT snapshots, except for the debian-security archive. This simplifies
      the documentation, the code, and eases reasoning about the whole thing.
      
      refs: #11612
      aed83f94
    • intrigeri's avatar
      0dcc9cf4
    • 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
  12. 25 May, 2016 3 commits
  13. 21 May, 2016 3 commits
  14. 17 May, 2016 5 commits
  15. 24 Mar, 2016 2 commits
  16. 11 Mar, 2016 1 commit