1. 11 Feb, 2016 1 commit
    • anonym's avatar
      Add set -u to all gettext:ized shell scripts. · 74a91c28
      anonym authored
      In gettext-base < 1.8.2, like the one we had in Wheezy, gettext.sh
      references the environment variable ZSH_VERSION, which we do not
      set. This has prevented us from doing `set -u` in all gettext:ized
      shell scripts unless we first initialize that variable before sourcing
      Now that we install a new enough gettext-base, we can finally do this
      and remove the initialization hacks.
      Will-fix: #9371
  2. 10 Feb, 2016 2 commits
    • anonym's avatar
      Do the fontconfig dance with all browsers. · a8021ec0
      anonym authored
      I.e. also the Unsafe and I2P Browser's. The main reason is so we do
      not need different images for these and the Tor browser in the
      automated test suite. One may argue, though, that for the Unsafe
      Browser this list of fonts would be fingerprintable, but I would be
      surprised if it already isn't so due to the Tor Browser Firefox
    • anonym's avatar
      Use an appropriate working directory when launching the Tor Browser. · 4173d78b
      anonym authored
      The Tor Browser assumes that the working directory is the directory
      where the browser lives (e.g. the executable). For instance, the
      fonts.conf (for fontconfig) the Tor Browser uses looks for the fonts
      in the "fonts" sub-directory of the current working directory. This
      will fix issues with "empty boxes" as characters in the Save As/Open
      Will-fix: #11097
  3. 09 Feb, 2016 5 commits
  4. 26 Jan, 2016 1 commit
  5. 03 Jan, 2016 1 commit
  6. 14 Dec, 2015 2 commits
  7. 10 Dec, 2015 1 commit
  8. 30 Nov, 2015 7 commits
  9. 19 Nov, 2015 1 commit
  10. 18 Nov, 2015 1 commit
    • anonym's avatar
      Remove useless code. · 598a0bf1
      anonym authored
      We only intend to run these script from environments where XAUTHORITY
      is set. Also, there is no ~/.Xauthority.
  11. 17 Nov, 2015 5 commits
  12. 12 Nov, 2015 2 commits
    • intrigeri's avatar
      Upgrader wrapper: make the check for free memory smarter. · b8a97e4f
      intrigeri authored
      Quoting anonym (#8263#note-1):
      In our Live system context, where a lot of stuff is in tmpfs:es, looking
      at the values of free or /proc/meminfo alone isn't accurate for
      determining how much memory "really" is free, since the tmpfs usage is
      included in the buffers. Hence, MemFree is the lower (and safe) bound of
      how much "really" free memory we have, and MemFree + Buffers + Cache is
      the upper (and unsafe) bound. The true value should be (at least closer
      to) MemFree + Buffers + Cache - (sum of usage by tmpfs:es). We should
      check once against that value instead.
      The 300 MB magic number (minimum "real memory" available) was found
      after bisecting with an ISO built from current feature/jessie:
       * with 278000 kB of "real memory" available, Tails Upgrader could
         successfully tell me that no upgrade was available (which is indeed
         the case), or that I should manually upgrade (after tweaking
         /etc/os-release; because I started from DVD);
       * with 255000 kB of "real memory" available, the check for upgrades
         failed and the desktop session froze;
      => so 300x1024 kB should give us a small safety margin.
      For the record, a VM with 1GB of RAM allocated (891 MB visible due to
      the QXL video adapter stealing some) on current feature/jessie has
      336MB (137MB free + 39MB buffers + 212MB cache - 52MB tmpfs) of "real
      memory" available once Tor is ready and Tor Browser is started, so in
      practice any system that's beefy enough to use Tails 2.0 can check
      for upgrades.
      Closes: #10540, #8263
    • intrigeri's avatar
      Revert "Lower required free (non-buffer/cache) memory for Tails Upgrader." · 220c9ce7
      intrigeri authored
      This reverts commit 01c88c1b.
      Refs: #8263
      Since then, we've bumped the memory requirements (both in our
      documentation and on the test suite's "hardware") to 2 GB, so the
      original reason for this change has gone away => let's go back to
      a value that was tested and confirmed to work (as in: allow upgrading
      a running Tails) on Wheezy, instead of a value that was tested on
      Jessie, but only for checking for available upgrades.
      The follow-ups will be:
       * the cool ideas posted on
         https://labs.riseup.net/code/issues/8263#note-1 will become a new,
         dedicated ticket (that has no reason to block the Tails 2.0 release);
       * #8083 and #7986 will tell us if the value this commit reverts to
         is OK.
  13. 26 Oct, 2015 1 commit
  14. 17 Oct, 2015 1 commit
  15. 07 Oct, 2015 3 commits
  16. 03 Oct, 2015 1 commit
  17. 17 Sep, 2015 1 commit
  18. 08 Sep, 2015 2 commits
  19. 18 Jul, 2015 2 commits