1. 11 Jul, 2020 1 commit
  2. 08 Mar, 2020 1 commit
    • Cyril 'kibi' Brulebois's avatar
      Add support for tails-workarounds (refs: #17323). · 060605c0
      Cyril 'kibi' Brulebois authored
      Make tails-workarounds directory available inside the chroot, so that
      its content can be used by any chroot local hooks.
      
      Chroot local includes seem to be the usual way to transfer things from
      the Tails checkout to the chroot environment; explicitly cleaning up
      /tmp afterwards doesn't seem to be needed.
      060605c0
  3. 06 Feb, 2020 1 commit
  4. 09 Jan, 2020 1 commit
  5. 01 Jan, 2020 1 commit
    • intrigeri's avatar
      Build system: key the website build cache on the input parameters that... · dccbff0e
      intrigeri authored
      Build system: key the website build cache on the input parameters that primarily determine its output (refs: #15342)
      
      As said when I reviewed anonym's initial implementation
      (5d07d53a), I was not satisfied by a cache that
      came with no automated invalidation mechanism at all, thus leaving up to each
      individual developer the "is this weird behavior caused by the cache?" analysis,
      and the manual invalidation of the cache.
      
      So, IMO we need to know when we can invalidate the cache, which is equivalent
      to: we need to know when a fresh build of the website would yield
      a significantly different output. This is what this commit does, by maintaining
      multiple cache directories, keyed to the input parameters that primarily
      determine the output of the website build. Note that I'm definitely not aiming
      for perfection here: for example, I did not list all the ikiwiki
      dependencies recursively.
      
      Finally, I'm also moving this cache to a dedicated storage volume, in order to
      support caching the website even when not using the 'vmproxy' option:
      
       - To start with, I don't use 'vmproxy' myself, but I would like to benefit from
         caching the website.
      
       - Furthermore, once we're confident enough in this caching mechanism, we could
         consider enabling it for our CI builds, that don't use 'vmproxy' either.
      dccbff0e
  6. 23 Dec, 2019 1 commit
  7. 04 Oct, 2019 1 commit
  8. 10 Aug, 2019 1 commit
    • intrigeri's avatar
      Don't try to follow symlinks when normalizing timestamps on source files. · c10f362d
      intrigeri authored
      This avoids this error during the build:
      
        touch: cannot touch 'config/chroot_local-includes/live/overlay': No such file or directory
        touch: cannot touch 'config/chroot_local-includes/lib/live/mount/persistence': No such file or directory
        touch: cannot touch 'config/chroot_local-includes/etc/apparmor.d/disable/usr.bin.man': No such file or directory
      
      Filtering out such errors when looking at a build log takes cycles.
      c10f362d
  9. 11 Jul, 2019 2 commits
  10. 19 May, 2019 5 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
      Drop obsolete check for syslinux version. · 802aa8ae
      intrigeri authored
      This version requirement is satisfied by Jessie and I doubt Tails would build in
      anything older.
      
      And anyway, we now only support building in Vagrant, which guarantees us we have
      a recent enough syslinux installed.
      802aa8ae
    • intrigeri's avatar
      auto/build: clone more build output to the log file. · 21b397a9
      intrigeri authored
      Previously we would start cloning the output later in auto/build, because we
      needed to do a bunch of things first, until we could figure out what the name of
      the build log file was. This is not the case anymore and we can thus generate
      a more complete build log.
      
      A future improvement would be to move this to the Rakefile or to build-tails,
      but that's more involved and I'm after low-risk, easy incremental improvements
      at the moment.
      21b397a9
    • intrigeri's avatar
      auto/build: drop support for GnuPG 1.x. · de3c8090
      intrigeri authored
      Our Vagrant build boxes are all Stretch nowadays.
      de3c8090
    • 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
  11. 11 Feb, 2019 1 commit
    • intrigeri's avatar
      Limit the memory used by mksquashfs to 512M (refs: #16177) · 1435cb75
      intrigeri authored
      By default mksquashfs will use 25% of the physical memory. So when we use the
      "ram" build option, build in a VM with 13GB of RAM, of which up to 12G is
      supposed to be used by the build tmpfs, mksquashfs will try using 13/4 = 3.25G
      of memory. And then it will get reaped by the OOM killer more or less
      occasionally depending on how much space is really used in the build tmpfs and
      how much memory the rest of the system is using. So let's limit the memory
      used by mksquashfs to 50% of the memory we allocate to the build VM,
      excluding the part of it that we expect tmpfs data to fill.
      
      In passing, the fact mksquashfs does not get killed every time suggests that our
      current BUILD_SPACE_REQUIREMENT value exceeds the real needs of a build: a value
      around 10 or 11G should be enough. But that will be for another commit.
      1435cb75
  12. 29 Jan, 2019 1 commit
    • intrigeri's avatar
      Limit the memory used by mksquashfs to 512M (refs: #16177) · 0892bff8
      intrigeri authored
      By default mksquashfs will use 25% of the physical memory. So when we use the
      "ram" build option, build in a VM with 13GB of RAM, of which up to 12G is
      supposed to be used by the build tmpfs, mksquashfs will try using 13/4 = 3.25G
      of memory. And then it will get reaped by the OOM killer more or less
      occasionally depending on how much space is really used in the build tmpfs and
      how much memory the rest of the system is using. So let's limit the memory
      used by mksquashfs to 50% of the memory we allocate to the build VM,
      excluding the part of it that we expect tmpfs data to fill.
      
      In passing, the fact mksquashfs does not get killed every time suggests that our
      current BUILD_SPACE_REQUIREMENT value exceeds the real needs of a build: a value
      around 10 or 11G should be enough. But that will be for another commit.
      0892bff8
  13. 15 Dec, 2018 1 commit
  14. 27 Nov, 2018 9 commits
  15. 14 Aug, 2018 1 commit
  16. 29 Jun, 2018 1 commit
  17. 27 Feb, 2018 2 commits
  18. 10 Nov, 2017 2 commits
    • intrigeri's avatar
      auto/build: normalize file timestamps in wiki/src before building (refs: #14933) · 0a484302
      intrigeri authored
      The copy of the website included in the ISO image has "Posted" timestamps that
      apparently match when we cloned the Git repository. This is expected since we
      build the website with the rcs setting disabled. Normalizing timestamps before
      building should fix this.
      
      What's surprising though is that only a few pages seem to be affected, while
      I would expect that all inlined pages without an explicit meta date should
      trigger the exact same problem. But anyway, normalizing mtime should fix it
      everywhere, so if it works, let's not bother investigating this further.
      
      One potential drawback of this commit is that it may make it harder to refresh
      an older, cached build of the website when we reintroduce this option in the
      future:  ikiwiki will have a hard time knowing which pages it should refresh.
      We'll see.
      0a484302
    • intrigeri's avatar
      auto/build: make list of directories more "git diff"-friendly. · dff0923b
      intrigeri authored
      This should be a no-op change.
      dff0923b
  19. 20 Oct, 2017 1 commit
  20. 04 Sep, 2017 1 commit
  21. 02 Sep, 2017 1 commit
    • intrigeri's avatar
      Merge base branch earlier, i.e. in auto/config instead of auto/build (refs: #14459). · 7396e42e
      intrigeri authored
      Previously, a given build from a topic branch would mix inconsistent versions
      of things. Most changes done in $topic_branch..$base_branch would be taken into
      account, but some would not, e.g. changes that affect:
      
       * everything we set up in auto/config, such as
          - copying tails-transform-mirror-url,
            gnome-shell-extension-florence-indicator
          - APT snapshots
          - debian/changelog, used by `apt-snapshots-serials prepare-build'
       * auto/build
      
      In practice, we've been suffering from some consequences of this problem
      e.g.:
      
       * ISO build failed on documentation branches based on master;
       * topic branches fail to build building once the APT snapshots they encode
         disappears, even though their base branch encodes newer & valid APT
         snapshots.
      
      This commit implements a cheap and partial fix: as stated on
      https://labs.riseup.net/code/issues/14459, the base branch merge still happens
      too late e.g. to take into account auto/config changes done in
      $topic_branch..$base_branch. Ideally we should do the base branch merge first
      thing in the build process, in a manner that's isolated from other build steps,
      so that *all* build code except the tiny script that performs the merge will be
      in the correct state.
      7396e42e
  22. 22 May, 2017 1 commit
  23. 17 May, 2017 1 commit
  24. 17 Apr, 2017 1 commit
  25. 16 Apr, 2017 1 commit