1. 12 Jun, 2014 1 commit
    • Tails developers's avatar
      Modify a fresh Iceweasel profile instead of the system one. · ed0a3862
      Tails developers authored
      If we're in camouflage mode we want it to be applied to the Unsafe
      Browser as well. However, the camouflage activation script modifies
      the *user's* own profile, not the system one, so it must be present at
      this point, and then it's easier to also make all the other changes to
      the user's profile since any changes to the system profile will not be
      copied back in.
  2. 11 Jun, 2014 1 commit
  3. 10 Jun, 2014 6 commits
  4. 07 Jun, 2014 1 commit
  5. 06 Jun, 2014 5 commits
  6. 05 Jun, 2014 2 commits
  7. 28 May, 2014 1 commit
  8. 27 May, 2014 8 commits
  9. 26 May, 2014 3 commits
  10. 23 May, 2014 1 commit
  11. 22 May, 2014 3 commits
  12. 20 May, 2014 5 commits
  13. 18 May, 2014 1 commit
  14. 16 May, 2014 1 commit
    • Tails developers's avatar
      Import new version of tor-launcher. · 4aa541b4
      Tails developers authored
      This is the standalone package generated from commit 4ad1ae8 on
      git://git.tails.boum.org/tor-launcher with the following locales:
            BUNDLE_LOCALES="ar de es fa fr it ko nl pl pt ru tr vi zh-CN"
      Changes since last import:
      * Now based on upstream Tor Launcher (from, with
        the following unreleased fixed:
        - Tor bug #11772: Proxy Type menu not set correctly
        - Tor bug #11699: Change &#160 to   in network-settings.dtd
        - Correctly handle startup paths that contain dot.
  15. 13 May, 2014 1 commit
    • Tails developers's avatar
      Require a bit less free memory before checking for upgrades. · 60ee6e88
      Tails developers authored
      The general goal is to avoid displaying "Not enough memory available to check
      for upgrades" too often due to over-cautious memory requirements checked in
      the wrapper.
      The specific goal is to avoid having to bump the hardware requirements for
      Tails 1.1 (Wheezy) to >> 1 GiB of RAM, as this would 1. not be very nice for
      users of oldish hardware; and 2. force us to implement #5502 ("Notify user if
      hardware requirements are not met") in time for the 1.1 freeze.
      My experiments, documented on #5390, indicate that even lower limits would
      probably work. Let's not be too adventurous to start with, though: my plan is to
      lower the limit to something that is low enough for the wrapper to dare running
      the check for upgrades, but still quite cautious.
      Later on, we could try lowering the limits even more, or even drop it entirely:
      this would require a mechanism to detect when the check for upgrades fails due
      to memory exhaustion, which don't have yet.
      Note that, if an automatic upgrade is available, Tails Upgrader checks memory
      again, to ensure there's enough free memory to apply the upgrade. This commit
      assumes that Tails Upgrader's own check is cautious enough, and that we were not
      implicitly relying on the check done earlier, in the wrapper, to ensure upgrade
      safety. This assumption might be wrong. My plan is to use the incremental
      upgrade to 1.1~rc1 as a test bench to verify this, as I have no time to fully
      test this fully right now (still, I successfully applied a small — 50 MiB —
      IUK on top of a current build from this very branch, with 126 MiB of free
      memory, and 700 MiB total free memory).
      The symptom of a failed upgrade due to lack of memory (and then, of a too low
      $mem_factor value in Frontend.pm) would be to see the upgrader that simply die
      in the middle of the download, or (worse) in the middle of the upgrade. In the
      worst case, the resulting (partially upgraded) system may not boot anymore, but
      no user data will be affected, and the user can still fix their stick by doing
      a full upgrade.