1. 31 Dec, 2019 1 commit
    • intrigeri's avatar
      Upgrader: catch more download errors · 9e31b582
      intrigeri authored
      As per https://metacpan.org/pod/LWP::UserAgent#request,
        Note that errors writing to the content file (for example due to permission
        denied or the filesystem being full) will be reported via the Client-Aborted
        or X-Died response headers, and not the is_success method.
      We were already handling X-Died specially, but not Client-Aborted,
      so there could be cases when we later treated the download as failed
      (due to size or hash mismatch) but did not report about the origin
      of the problem, which would make debugging of user bug reports harder.
  2. 29 Dec, 2019 7 commits
  3. 27 Dec, 2019 3 commits
    • intrigeri's avatar
      Release process: adapt garbage collection of IUKs to the single SquashFS diff... · 6b454c60
      intrigeri authored
      Release process: adapt garbage collection of IUKs to the single SquashFS diff upgrade scheme (#15284)
      In the single SquashFS diff upgrade scheme, we'll generate and publish many more
      IUKs and will need to delete obsolete ones more aggressively. The good news is
      that we have a much better criterion for that than the age of an IUK: since
      every new release will have IUKs that upgrade to this new release from any older
      version that has the same "X" as the new release in "version X.Y", we know
      it follows that any IUK that upgrades to anything but the version that
      was just released is obsolete and can go away.
      So essentially, at any point in time, our mirrors will store the set of IUKs
      that upgrade to the current version of Tails, and that's it. The only exceptions
       - IUKs v1, that we'll need to garbage collect manually at a well chosen time;
         this is a one-time cleanup operation and does not seem worth automating;
       - In the release process, between the time the IUKs for the new release
         are uploaded, and the time when the RM goes this this post-release
         cleanup step, our mirrors will store 2 sets of IUKs: those that upgrade
         to the previous version, and those that upgrade to the new one.
    • intrigeri's avatar
      Store IUKs v2 in a dedicated directory (#15281) · a9fa544b
      intrigeri authored
      At least in theory, there can very well be, for example, both IUKs v1 and v2
      that upgrade from 4.1 to 4.3 and have the same filename. The difference
      will be the meaning of "from 4.1" and the content.
      Let's avoid having to deal with that.
    • intrigeri's avatar
      Upgrader test suite: fix by making the signing key available on the test web server (#15279) · 2ccd9426
      intrigeri authored
      Fixes test suite regression introduced
      in cced26b6.
  4. 26 Dec, 2019 2 commits
    • intrigeri's avatar
      IUK creation: delete temporary directory on success (refs: #15287) · 1501f638
      intrigeri authored
      tails-create-iuk previously left temporary files behind. In particular, even on
      success, the "squashfs_src" directory would remain on the filesystem.
      It's no big deal in general, but our build_IUKs Jenkins job runs
      tails-create-iuk as root with sudo, so the leftover temporary files are owned by
      root, and then the "workspace-cleanup" step (itself run as the "jenkins" user)
      can't delete them, which causes 2 problems:
       - These temporary files would endlessly accumulate on isobuilders,
         without any mechanism to clean them up automatically.
       - Confusing output in the Jenkins console:
            cannot remove path when cwd is /var/lib/jenkins/workspace/build_IUKs/j4gMvgS3wH for /var/lib/jenkins/workspace/build_IUKs/j4gMvgS3wH:  at /usr/share/perl/5.24/File/Temp.pm line 1583.
            Archiving artifacts
            [WS-CLEANUP] Deleting project workspace...
            Cannot delete workspace: null
            Option not to fail the build is turned on, so let's continue
    • intrigeri's avatar
      IUK creation: only pass --xattrs to rsync when using overlayfs · a61ffaae
      intrigeri authored
      On our Stretch isobuilders, passing --xattrs to rsync when generating an
      aufs-based IUK makes it fail: setting xattrs on a file in an aufs filesystem
      raises an "operation not supported" error.
      We only need to preserve xattrs when building overlayfs-based IUKs,
      because aufs will lose them at mount time anyway.
  5. 25 Dec, 2019 1 commit
  6. 24 Dec, 2019 8 commits
  7. 23 Dec, 2019 18 commits