| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Mike tells me that these are no longer necessary since #3443 ("Client
with low CBT can't establish any circuits") was fixed. I removed the
config from my hourly tests and it doesn't seem to increase the number
of failures.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
It seems to be needed in makexpi.sh. My guess is that python was usually
installed incidentally by a previous build step, and you would see an
error only if you started the bundle step with a clean VM.
https://trac.torproject.org/projects/tor/ticket/10387
|
| |
|
|
|
| |
Copied from /pluggable-transports/bundle.git/doc
86efa19e1d7fb8f75cd1d9b126d40263658d27bb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bridges are commented out. With #5018, we could leave in
ClientTransportPlugin lines, and tor would not start them until there is
a Bridge line that needs them. #5018 is only merged into 0.2.5 at this
point.
https://trac.torproject.org/projects/tor/ticket/5018
Even more forward-looking, we might need another way to take care of
transports that discover their own bridges, and want to run even without
bridges configured.
https://trac.torproject.org/projects/tor/ticket/5018#comment:17
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch prevents transport plugins from being started if there is no
bridge that needs them. It corresponds to merge
4b6f074df9c540cb4847793b7e8243c8f642de0a in the tor repo.
I made it by doing
git format-patch master..bug5018
git cat 000* > bug5018.patch
in the tor repo, then I applied it on top of tor-0.2.4.18-rc with
GIT_COMMITTER_NAME="nobody" GIT_COMMITTER_EMAIL="nobody@localhost" GIT_COMMITTER_DATE="2000-01-01 00:00:00" git am bug5018.patch
and did another format-patch and cat.
|
| |
|
|
|
|
| |
This is the patch from #10297, that causes Tor to set the
CREATE_NO_WINDOW flag so console windows don't appear. It has been
applied to tor master but not yet to TOR_TAG.
|
| |
|
|
|
|
|
|
|
|
|
| |
These values are included in the commit hash (which is in turn included
in the tor source code as tor_git_revision).
GIT_COMMITTER_NAME is probably always "Ubuntu" in our configuration, and
GIT_COMMITTER_DATE isn't strictly needed as it's taken care of by
libfaketime. But GIT_COMMITTER_EMAIL, if not set, is constructed as
something like "ubuntu@$(hostname --fqdn)", which can vary between hosts
even within the build VM.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using "git am" to apply a patch was failing randomly using git version
1.7.0.4 on the lucid i386 and amd64 images. The error message was:
ubuntu@ubuntu:~/build/tor$ git am ~/build/0001-Set-CREATE_NO_WINDOW-in-tor_spawn_background.patch
Applying: Set CREATE_NO_WINDOW in tor_spawn_background.
error: src/common/util.c: does not match index
Patch failed at 0001 Set CREATE_NO_WINDOW in tor_spawn_background.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
I could log in and run the command manually; it would fail perhaps 10%
of the time. The rest of the time it would work as expected. What I mean
is that I could set the working tree to the tag tor-0.2.4.18-rc using
either of
git checkout tor-0.2.4.18-rc
git reset --hard tor-0.2.4.18-rc
try running the "git am" command, and sometimes it would work, sometimes
not. I would reset the state of the tree and again, sometimes it would
work, and sometimes not. I checked many times using "git status" and
"git ls-files -s" to see that there were no changes and nothing staged
in the working tree.
I believe the cause of the error is the bug fixed by this commit:
"am: refresh the index at start and --resolved"
https://github.com/git/git/commit/2a6f08ac1f6949ed0072aed3240bc04d80051851
It doesn't seem to have made it into the release notes, but according to
the history it first appeared in 1.7.6.1.
See also the email thread leading to the commit:
http://git.661346.n2.nabble.com/quot-git-apply-check-quot-successes-but-git-am-says-quot-does-not-match-index-quot-td6684646.html
I never got this error with "git am" for the windows build on the
precise i386 VM, which has git version 1.7.9.5, which fits with the
problem being a git bug that has since been fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For each extension module, py2exe generates and byte-compiles a tiny
stub .py file that loads the module:
creating python loader for extension 'bz2' (Z:\home\ubuntu\install\python\DLLs\bz2.pyd -> bz2.pyd)
These .py stubs are dynamically generated at py2exe time, so we don't
have an opportunity to set the mtime of .py files ahead of time. But we
can set the .pyc timestamps after the fact.
I believe this commit makes bd4b3de712e345adc20ec9e959759f03da5826bc
superfluous, but I'm leaving that one because I hope there is a nicer
way to do this one.
|
| | |
|
| |
|
|
|
|
|
| |
.pyc files contain the mtime of the .py file used to produce them. I
couldn't find a way to prevent py2exe from byte-compiling .pyc files.
http://benno.id.au/blog/2013/01/15/python-determinism
|
| |
|
|
|
|
| |
py2exe run under Wine doesn't get this file, so copy it in manually.
http://bugs.winehq.org/show_bug.cgi?id=3591
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The step of creating zope/__init__.py is needed so that py2exe can find
the package.
This need was previous discovered:
https://gitweb.torproject.org/pluggable-transports/bundle.git/commitdiff/4482c5f5ad63b320e6208547a091f47005394ec9
then removed because easy_install made it unnecessary:
https://gitweb.torproject.org/pluggable-transports/bundle.git/commitdiff/64044647bf5412e5aa3a930a577e1dbb8cd91276
Now we need it back because we're not using easy_install.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc.exe, dllwrap.exe, and swig.exe need to be actual executables. If you
merely rename gcc.py and dllwrap.py, the programs run, but they
immediately detach themselves from the shell and run in the background.
So when py2exe calls a bunch of programs in series:
gcc -o file1.o file1.c
dllwrap file1.o
gcc -o file2.o file2.c
dllwrap file2.o
gcc -o file3.o file3.c
dllwrap file3.o
all the programs would run essentially simultaneously. dllwrap wasn't
waiting for gcc to finish writing the object file that it (dllwrap)
needed as input.
(You could actually get a successful build out of this, if you ran
build_ext once, waiting a few seconds for all the gccs to finish, then
ran it again. The second time, distutils would notice that the object
files already existed, and run only the dllwrap commands, which would
succeed because the object files were already in place.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python distutils, with the "mingw32" compiler profile, is inflexible. It
hardcodes the names "gcc.exe" and "dllwrap.exe", and passes them fixed
options. It's not possible to control it with environment variables like
CC and CFLAGS.
Before Python 2.7.6, distutils always passes the option -mno-cygwin to
gcc, which causes an error. Additionally, when distutils is run under
Wine, it passes Windows-style paths with backslashes to our unsuspecting
i686-w64-mingw32-gcc.
These wrapper programs strip -mno-cygwin, and convert Windows paths to
Unix paths. They also set LD_PRELOAD and FAKETIME, because those can't
be set for the outer Wine process.
Doing a subprocess.Popen of a Unix program from within Wine mostly
works. For example, subprocess.Popen(["/usr/bin/i686-w64-mingw32-gcc"])
starts a new compiler process. However, if you .wait() on the process
object, you get a "WindowsError: [Error 6] Invalid handle". The same
goes for the implicit wait in subprocess.call and
subprocess.check_output. The .pid of such processes is 0.
What you can do, however, is read from one of the process's output
streams--it will be closed when the process terminates. Because we know
we are dealing with gcc subprocesses, we read its stderr and look for
the string " error: ". If it appears, we return a non-zero status code.
We don't return non-zero merely on a non-empty stderr, because warnings
don't usually cause that.
The difficulty doesn't exist when running native Windows binaries.
That's why we can do subprocess.call(["winepath", ...]): because
winepath.exe is a native binary that comes with Wine.
|
| |
|
|
|
|
| |
The only binary distribution is a self-installing executable, and I
couldn't find a way to make it run from the command line. So extract it
with 7z and copy its contents.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main reason for a newer wine is to work around an issue in the
Ubuntu's standard wine1.4 that often manifests when running Python code,
leading to a page fault.
"blender 2.61 crashes on start (python3.2)
http://bugs.winehq.org/show_bug.cgi?id=29764
"EVE Online crashes when viewing certain ship models (T3 ships)"
http://bugs.winehq.org/show_bug.cgi?id=30515
The crash is triggered by the _PyVerify_fd function, which peeks at a
Windows-internal data structure, implicitly expecting it to have been
allocated on the heap.
http://hg.python.org/cpython/file/694e2708b4a8/Modules/posixmodule.c#l1078
Wine 1.4 doesn't do this structure in the way Python expects, leading to
the page fault. _PyVerify_fd is called by many Python functions that
deal with file descriptor numbers, such as io.open and os.fstat. This is
sufficient to crash Python run under Wine 1.4:
>>> import os
>>> os.fstat(4)
(The crash is actually at RtlHeapSize, called by _msize, called by
_PyVerify_fd.) I initially tried to patch around such problematic calls,
but they are too pervasive.
When running wineboot or any other Wine command, it is necessary to
remove libfaketime from LD_PRELOAD.
"[Bug 31237] New: libfaketime: integrate with libfaketime to allow running a program with a fake time"
http://bugs.winehq.org/show_bug.cgi?id=31237
My experience matches what appears in the bug report. With libfaketime
in LD_PRELOAD, I got this error every time I ran a Wine command:
wine: created the configuration directory '/home/ubuntu/.wine'
wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 000b),
err:seh:start_debugger Couldn't start debugger ("winedbg --auto 10 104") (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0011),
err:seh:start_debugger Couldn't start debugger ("winedbg --auto 16 68") (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
|
| |
|
|
|
|
|
| |
https://launchpad.net/~ubuntu-wine/+archive/ppa
http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x5A9A06AEF9CB8DB0.
gpg --output gpg/ubuntu-wine.gpg --export --export-options export-minimal 0x5A9A06AEF9CB8DB0
|
| | |
|
| | |
|
| |
|
|
| |
Empty except for copied openssl build from gitian-tor.yml.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gpg --output gpg/PYTHON_MSI.gpg --export --export-options export-minimal 0x7D9DC8D2
We need to have a Python installation in order to compile various Python
packages. On GNU/Linux, we can use a python-dev package. The Mac OS X
SDK contains a Python "framework." I tried cross-compiling Python using
the mingw-w64 tools, but that seems unsupported and likely to require
many third-party patches.
"cross and native build of python for mingw* hosts"
http://bugs.python.org/issue3871
"Add support for mingw"
http://bugs.python.org/issue6335
"Cross compilation patches and build scripts for CPython"
https://github.com/mingwandroid/crucifixion-freedom
"Cross compilation patches for Python 2.7.3 and 3.3.0, targeting
MinGW/Darwin/Linux and MinGW builds generated from these."
https://code.google.com/p/mingw-and-ndk/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears that we must use a Python that is compatible with the
compiled Python modules we provide. Apple's custom python binary
provides environment variables to control the version and word length:
VERSIONER_PYTHON_VERSION=2.6
VERSIONER_PYTHON_PREFER_32_BIT=yes
See python(1).
With neither of these variables set, on OS X 10.9, importing a module
results in:
ImportError: dlopen(TorBrowserBundle_en-US.app/Tor/Crypto/Cipher/_AES.so, 2): no suitable image found. Did find:
/Users/david/TorBrowserBundle_en-US.app/Tor/Crypto/Cipher/_AES.so: mach-o, but wrong architecture
The same happens if VERSIONER_PYTHON_VERSION=2.6 but
VERSIONER_PYTHON_PREFER_32_BIT is unset.
Setting VERSIONER_PYTHON_PREFER_32_BIT=yes without setting
VERSIONER_PYTHON_VERSION causes this message in the terminal along with
a popup offering to send a crash report:
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap: 6
Setting both variables seems to work.
This issue may be a manifestation of that our compiled modules are
i386-only:
$ file Crypto/Cipher/_AES.so
Crypto/Cipher/_AES.so: Mach-O dynamically linked shared library i386
Whereas /usr/bin/python is both 32-bit and 64-bit. The 2.x series of PT
bundles used fat shared objects and didn't show this problem.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
