- Nov 12, 2017
-
-
Georg Koppen authored
-
Georg Koppen authored
We can't use the --remove-update-channel option as we envisioned in #10394 as this throws an error in the WebExtensions context in Tor Browser. Falling back to regular EFF updates for now.
-
- Nov 10, 2017
-
-
Georg Koppen authored
-
Georg Koppen authored
-
- Nov 09, 2017
-
-
Georg Koppen authored
-
Georg Koppen authored
Versions bump and Changelog update
-
Georg Koppen authored
-
boklm authored
-
boklm authored
-
boklm authored
-
boklm authored
-
boklm authored
-
boklm authored
-
boklm authored
-
boklm authored
-
-
Georg Koppen authored
Due to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1392604 we disable STL wrappers for now. For some reason only 64bit Windows builds are affected. Thus we restrict the disabling only to them leaving all other targets unaffected.
-
Georg Koppen authored
-
Georg Koppen authored
This reverts commit e0e6bfd7.
-
Georg Koppen authored
This reverts commit 409a6951.
-
- Nov 08, 2017
-
-
boklm authored
-
Georg Koppen authored
We use the new --remove-update-channel switch to prevent HTTPS Everywhere from pinging update servers and updating automatically like we do with Torbutton and Tor Launcher. The new HTTPS Everywhere build file makes the workaround for bug 10066 obsolete as well.
-
- Nov 06, 2017
-
-
boklm authored
In projects/debootstrap-image, the option var/osname is not defined, so the build_log filename was logs/debootstrap-image-.log.
-
boklm authored
-
boklm authored
Fix the build of openssl and zlib for Windows 64.
-
Add torbrowser-windows-x86_64 support to rbm.conf. Update mingw-w64 to use the x86_64-w64-mingw32 target (instead of i686-w64-mingw32) for torbrowser-windows-x86_64 builds.
-
- Nov 02, 2017
-
-
Georg Koppen authored
-
Georg Koppen authored
-
Georg Koppen authored
-
Georg Koppen authored
-
- Oct 23, 2017
- Oct 18, 2017
-
-
Georg Koppen authored
Changelog update and version bumps
-
Added flags: -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Werror=format -Werror=format-security
-
-
- Oct 17, 2017
-
-
boklm authored
-
- Oct 04, 2017
-
-
boklm authored
Some distributions are packaging runc version 1.0.0~rc2, which seems to be half between runc 0.1.1 and runc 1.0.0. This version requires the same command line parameters as version 1.0.0, however it requires a config.json in the same format as 0.1.1. The output from `runc --version` on 1.0.0~rc2 is: runc version spec: 1.0.0-rc2-dev So we add a var/runc_spec100 function which is true when the runc version spec is exactly 1.0.0 (as returned by runc stable 1.0.x releases), and use it in projects/common/runc-config.json.
-
- Oct 03, 2017
-
-
Georg Koppen authored
-
- Oct 02, 2017