1. 11 Jul, 2019 2 commits
  2. 22 Oct, 2018 1 commit
  3. 28 Aug, 2016 2 commits
    • 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
      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
  4. 08 Jun, 2016 1 commit
  5. 22 May, 2016 1 commit
  6. 21 May, 2016 2 commits
  7. 18 May, 2016 1 commit
  8. 12 May, 2016 1 commit
  9. 15 Apr, 2016 1 commit
  10. 31 Mar, 2016 2 commits
  11. 12 Feb, 2016 1 commit
  12. 28 Oct, 2015 1 commit
  13. 27 Oct, 2015 2 commits
    • intrigeri's avatar
      Fix typos. · 7dcf1bec
      intrigeri authored
      7dcf1bec
    • intrigeri's avatar
      Start adjusting documentation to the fact we're going to have 3 kinds of APT repositories. · b01fe534
      intrigeri authored
      The existing one, with Tails-specific packages, is now called our "custom APT
      repository". On top of that, we'll soon have time-based snapshots and tagged
      snapshots of upstream APT repositories.
      
      This commit adjusts a small part of this documentation, but mainly:
      
       * reworks the files and directories layout;
       * adjust links accordingly;
       * adds XXX placeholders where new documentation must be written, or existing
         documentation must be updated.
      b01fe534
  14. 30 Jun, 2015 2 commits
  15. 11 May, 2015 1 commit
  16. 04 May, 2015 1 commit
  17. 14 Apr, 2015 1 commit
  18. 08 Apr, 2015 3 commits
  19. 05 Apr, 2015 1 commit
  20. 01 Apr, 2015 2 commits
  21. 31 Mar, 2015 2 commits
  22. 26 Feb, 2015 1 commit
  23. 25 Feb, 2015 1 commit
    • intrigeri's avatar
      Move to GitLab for the "fork us on.." documentation. · 705dc3c1
      intrigeri authored
      Its UI is way nicer than repo.or.cz, it is easier to configure, it offers HTTPS,
      and most importantly we can easily push there ourselves (to get an up-to-date
      mirror, and e.g. remove old tags or rewrite history) as opposed to our old
      mirror-style repo on repo.or.cz.
      705dc3c1
  24. 15 Jan, 2015 1 commit
  25. 11 May, 2014 1 commit
  26. 04 Apr, 2014 1 commit
  27. 14 Mar, 2014 1 commit
  28. 24 Feb, 2014 1 commit
  29. 16 Feb, 2014 1 commit
  30. 30 Nov, 2013 1 commit