1. 11 Jul, 2020 1 commit
  2. 18 May, 2020 1 commit
  3. 23 Nov, 2019 1 commit
  4. 19 Oct, 2019 1 commit
  5. 03 Oct, 2019 1 commit
  6. 12 Sep, 2019 1 commit
  7. 16 Aug, 2019 2 commits
  8. 11 Jul, 2019 2 commits
  9. 24 May, 2019 1 commit
  10. 19 May, 2019 4 commits
    • intrigeri's avatar
      auto/build: drop checks for conditions that are satisfied in supported build environments. · 54beec54
      intrigeri authored
       - isohybrid is available in our Vagrant build VMs. The manual build
         documentation is totally outdated and broken, nobody complained about it,
         which suggests nobody tried to follow it since 1+ years.
         And anyway, if isohybrid is not installed, the build will fail loudly
         later on.
      
       - $LB_BINARY_IMAGES is correctly set because auto/config passes
         "--binary-images iso" to "lb config". Checking it here brings no value and
         just makes things harder for anyone who would want to add support for other
         kinds of images.
      
       - It's been a while since we've stopped releasing source tarballs :) One can't
         reach auto/config via "rake build" if one is not building from Git, and
         building without rake is unsupported (good luck with that).
      54beec54
    • intrigeri's avatar
      auto/{build,config}: prefix informational message with "I: " · bca6a4c8
      intrigeri authored
      This will help understand, while looking at a build failure log, what's an
      informational message we've intentionally printed vs. what's additional info (or
      noise) produced by tools we call.
      
      This convention is used in many Debian things and in some of our
      own source code already.
      bca6a4c8
    • intrigeri's avatar
      auto/config: consistently use fatal() to error out. · 0fb051b2
      intrigeri authored
      We're using fatal() in many places in this script already, but not everywhere.
      As a result, some error messages were printed to STDOUT while some others went
      to STDERR. Let's be consistent.
      0fb051b2
    • intrigeri's avatar
      Honor $BASE_BRANCH_GIT_COMMIT (refs: #16730) · 211f15af
      intrigeri authored
      So far we relied on a hack in our Jenkins job (set_origin_base_branch_head) to
      tweak Git state in a way that git_base_branch_head gets it right. But that's
      complex, fragile, and interacts badly with the refs mangling we do in
      build-tails. So let's instead honor a pre-existing $BASE_BRANCH_GIT_COMMIT, so
      we can drop the set_origin_base_branch_head hack from the Jenkins job.
      
      What I'm doing here seems to have been the original intent of the work that was
      done on #11972: f4a20a41 and
      49c29304 have started work in this direction,
      that was never finished, and $BASE_BRANCH_GIT_COMMIT was left entirely unused,
      which confused me a great deal when starting to work on this.
      
      Incidentally, this change makes $BASE_BRANCH_GIT_COMMIT behave in the same way
      as $GIT_COMMIT (which is already taken from the environment if set), which
      is more consistent and less confusing.
      
      Commit c579fc97df8ea41dda67e24047cae131b2425250 in jenkins-jobs.git
      sets $BASE_BRANCH_GIT_COMMIT to the commit that the base branch was in
      during the first build, that we're trying to reproduce.
      211f15af
  11. 02 Dec, 2018 2 commits
    • intrigeri's avatar
      When testing ISO build reproducibility, use the same APT snapshots in both builds (refs: #15107). · 2da49e69
      intrigeri authored
      Problem:
      
       - Our branches based on devel use "latest" snapshots for every APT archive used
         at build time => their reproducibly_build_Tails_ISO_* job will fail if any of
         these APT snapshots is updated between the start of the original build job
         and the start of the reproducibly_build_Tails_ISO_* job.
      
       - Our branches based on stable are also affected, but to a lesser degree: they
         use the "latest" snapshot only for the debian-security archive.
      
       - Any branch can be affected when the build is triggered by a Git push at an
         unfortunate time. But for some branches, the automatic daily build is
         _always_ affected: daily Jenkins job runs are scheduled in a deterministic
         manner, with a schedule based on the name of the branch. So inevitably, the
         automatic daily rebuild of _some_ branches will always fail to build
         reproducibly, because the failure condition ("APT snapshots is updated
         between the start of the original build job and the start of the
         reproducibly_build_Tails_ISO_* job") will always be met. There's no such
         active branch at the moment but we've seen that happen in the past.
      
      To fix that, let's ensure we use the same APT snapshots during the second build
      as the ones the first build used. Here's how.
      
      With this commit, we save the serials an ISO build used as a build artifact that
      the downstream reproducibly_build_Tails_ISO_* CI job will copy and then load
      environment from (using the Jenkins EnvInject Plugin).
      
      Therefore, in a given reproducibly_build_Tails_ISO_* CI job run, the
      APT_SNAPSHOTS_SERIALS environment variable will tell what APT snapshots were
      used by its upstream build_Tails_ISO_* CI job run. And finally, thanks to
      commit:aafdf8da and follow-ups, that downstream
      reproducibly_build_Tails_ISO_* CI job run will reuse the same snapshots.
      2da49e69
    • intrigeri's avatar
      Rename APT_SNAPSHOT_SERIALS → APT_SNAPSHOTS_SERIALS (refs: #15107) · d8db001f
      intrigeri authored
      This is more consistent with the naming of the corresponding
      apt-snapshots-serials* scripts.
      d8db001f
  12. 18 Nov, 2018 1 commit
    • intrigeri's avatar
      Remove the boot readahead feature (refs: #15915). · eaf91f2e
      intrigeri authored
      Our work on the USB image project (#15292) will deprecate booting from DVD
      except for VMs. So the use cases we'll still support are:
      
       - booting from a USB stick
       - booting a VM from an ISO
      
      In both cases, readahead does not matter much (or at all), so let's
      simplify things.
      eaf91f2e
  13. 14 Aug, 2018 1 commit
  14. 29 Jun, 2018 2 commits
    • intrigeri's avatar
      Install all "Priority: standard" packages via an explicit packages list... · 6e170f3f
      intrigeri authored
      Install all "Priority: standard" packages via an explicit packages list instead of via --tasks (refs: #15690)
      
      This will make it easier to remove some of these packages from the list
      of those that should be installed in the first place, as opposed to letting them
      be installed by tasksel only to uninstall them later.
      
      I've seeded tails-000-standard.list with the output of:
      
        tasksel --task-packages standard | sort
      
      … run on a clean Stretch system.
      
      Also:
      
       * live-build forcibly translates --packages-lists="standard" into "tasksel
         install standard", so to make this change effective we also need to switch
         to "--packages-lists minimal" or "--packages-lists none". The former has
         problematic side-effects so let's use the latter.
      
       * Add to tails-common.list some of the packages that were previously installed
         automatically, e.g. via live-build's lists/standard → lists/minimal.
      6e170f3f
    • intrigeri's avatar
      Rename /usr/share/amnesia to /usr/share/tails. · e15c24a9
      intrigeri authored
      The project was renamed, what, 8 years ago?
      e15c24a9
  15. 27 Feb, 2018 1 commit
  16. 19 Feb, 2018 1 commit
  17. 17 Jan, 2018 1 commit
    • intrigeri's avatar
      Have debootstrap install gnupg when setting up the chroot. · 787b1702
      intrigeri authored
      Otherwise the build fails after debootstrap has done its job
      and live-build tries to use apt-key:
      
        I: Base system installed successfully.
        P: Begin caching bootstrap stage...
        P: Begin unmounting filesystems...
        P: Setting up cleanup function
        P: Begin caching chroot stage...
        P: Begin mounting /dev/pts...
        P: Begin mounting /proc...
        P: Begin mounting /sys...
        P: Configuring file /etc/debian_chroot
        P: Configuring file /sbin/start-stop-daemon
        P: Configuring file /usr/sbin/policy-rc.d
        P: Configuring file /usr/sbin/initctl
        P: Configuring file /etc/hosts
        P: Configuring file /etc/resolv.conf
        P: Configuring file /etc/hostname
        P: Configuring file /bin/hostname
        P: Configuring file /etc/apt/apt.conf
        P: Configuring file /etc/apt/sources.list
        E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation
      787b1702
  18. 05 Jan, 2018 5 commits
  19. 01 Jan, 2018 1 commit
    • bertagaz's avatar
      Add APT_SNAPSHOT_SERIAL build option. · aafdf8da
      bertagaz authored
      It enables to specify which time-based APT snapshot repositories will be
      used as 'latest' during the build, and will set it accordingly in the
      resulting ISO image. Useful to reproduce another ISO image.
      
      Refs: #15107, #14944, #14924
      aafdf8da
  20. 16 Dec, 2017 1 commit
  21. 10 Nov, 2017 1 commit
  22. 20 Oct, 2017 1 commit
  23. 05 Oct, 2017 2 commits
    • anonym's avatar
      Revert "Revert "Disable APT security sources." (refs: #12309)" · 7762d0ec
      anonym authored
      This reverts commit ba01dfb5.
      
      Now we have to disable the Debian security APT sources again, but for
      feature/buster.
      
      Refs: #12309
      7762d0ec
    • 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
  24. 22 Sep, 2017 2 commits
  25. 18 Sep, 2017 1 commit
    • intrigeri's avatar
      auto/config: abort if tails-custom-apt-sources failed. · d3d2b7e1
      intrigeri authored
      Currently the build of our devel branch fails in a confusing manner.
      
      tails-custom-apt-sources fails this way:
      
       + tails-custom-apt-sources
       base_branch: testing
       current_branch: devel
       In a base branch, config/base_branch must match the current branch.
      
      … but the build goes on, and fails later when we try installing packages
      that are only found in our custom APT repository, because no APT source
      pointing to that repository was set up.
      
      Let's avoid this and fail earlier when we know the build can't possibly succeed.
      d3d2b7e1
  26. 12 Sep, 2017 1 commit
  27. 06 Sep, 2017 1 commit