| Commit message (Collapse) | Author | Age |
| |\
| |
| |
| | |
This is mainly to get the git-gpg-wrapper fix.
|
| | |
| |
| |
| | |
Thanks to dcf for finding the cause of the problem.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Changelog update, version bumps, and config.yml update
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This reverts commit e8178d1373d6ce2599ef58eca4d52d1b6817263f.
That's properly fixed in NoScript >= 5.0.7.1, thus removing our
workaround.
|
| | | |
|
| | |
| |
| |
| | |
This fixes bug 22067.
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We bump our GCC compiler to 5.4.0 as this fixes some bugs
in previous versions. It allows us in particular to build
debug builds for Windows with mingw-w64.
|
| | |
| |
| |
| | |
Found by boklm.
|
| | |
| |
| |
| | |
Whitelist about:tor so that NoScript does not block its JavaScript.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I had to apply two tricks to get a reproducible snowflake-client.
The first is to use faketime to eliminate some timestamps. There were 11
variable timestamps in the file. Through experimentation, I found that
10 of them were dependent on the Go runtime (recompiling Go caused them
to change) and 1 was dependent on snowflake-client itself (recompiling
snowflake-client with the same runtime changed only that 1 timestamp).
The underlying issue has to do with clang 3.8.0 on Darwin embedding
timestamps, unsolved in the Go issue tracker as of 13 days ago.
https://github.com/golang/go/issues/9206#issuecomment-310476743
The second is a sed command to clobber embedded paths of the form
/tmp/go-buildXXXXXXXXX and /tmp/go-link-XXXXXXXXX. Their presence is
caused by some combination of Clang and Darwin, and there is as yet no
known workaround upstream.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Object files from elsewhere under out/ should never have been included,
because they are not part of webrtc itself, but rather side-effect build
artifacts like gn. Including those extraneous .o files was mostly
harmless (except for library size), because on linux they happened to be
the same architecture as the webrtc.o files. However it won't work for
the mac build (because libwebrtc-magic.a would include a mix of linux
ELF and mac Mach-O objects). Additionally, build_time.o, part of the gn
build, embeds a timestamp with month resolution, causing a failure of
reproducibility, as found at https://bugs.torproject.org/22832.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This is apparently an unsolved bug having to do with current versions of
Clang on Darwin.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There were 11 variable timestamps in the file. Through experimentation,
I found that 10 of them were dependent on the Go runtime (recompiling Go
caused them to change) and 1 was dependent on snowflake-client itself
(recompiling snowflake-client with the same runtime changed only that 1
timestamp).
The underlying issue has to do with clang 3.8.0 on Darwin embedding
timestamps, unsolved in the Go issue tracker as of 6 days ago. (That
version of clang also embeds variable absolute paths, which is not
handled by this commit.)
https://github.com/golang/go/issues/9206#issuecomment-310476743
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This sets timestamps inside the archive to zero. The variable timestamps
were eventually finding their way inside of snowflake-client.
|
| | |
| |
| |
| |
| |
| | |
Currently the windows code doesn't work and crashes during the build.
Remove it until it's working so we can run a start-to-finish build
(including windows sans snowflake) in this branch.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The one built by bootstrap/bootstrap.py is crashing in this way:
debian@debian:~/build/webrtc/src/build/config$ "$GN" gen out/Release --args="$GN_ARGS"
[0624/022439.767916:FATAL:command_gen.cc(59)] Check failed: !rule.empty().
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x41f2b5]
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x41184b]
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x55f0f7]
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x534241]
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x45540a]
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x455ca1]
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x4571fa]
/home/debian/build/webrtc/src/out_bootstrap/gn() [0x423973]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8064) [0x7f17fa23b064]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f17f9f7062d]
Aborted
|
| | | |
|
| | |
| |
| |
| | |
Doesn't build yet because of changes from Chromium branch-heads/58.
|
| |\ \
| |/
| |
| | |
Tagging build2 for 7.5a1
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
"10.9" was the wrong `minSupportedOSVersion` for preventing OS X 10.7.x
and 10.8.x users from getting updated to Tor Browser 7. That it worked
for OS X 10.6.x was only by chance according to the release history table
(https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history).
We fix that by choosing "13.0.0" (for OS X 10.9 as minimum).
|
| | | |
|