| Age | Commit message (Collapse) | Author |
|---|
|
This is a first step towards moving all of the Cryptech code from
Python 2 to Python 3. At this stage, the goal is to make the same
source code work in both language dialects, and to build packages
which install both versions of the library code.
This is a necessary step along the way, but since Python 2 is already
past EOL as of this writing and since some distributions have started
dropping all support for Python 2, we will almost certainly want to
drop all Python 2 support in the relatively near future, if only
because it's not really to do all the packaging right for both
versions at once without much more trouble than a dead language
dialect is probably worth. All platforms we care about should support
Python 3 already, any that don't probably have much worse problems.
So the primary purpose of pushing this particular commit is to archive
what will probably be the last version supporting Python 2, while
giving folks a chance to test the incoming Python 3 support a bit.
Once we've cut loose from Python 2 for good, there's some cleanup we
can and should do (eg, all the gymnastics to work around Python 2's
handling of bytes as a form of text rather than a sequence of small
integers), but for the moment we want to keep that compatability,
albeit briefly.
|
|
Prior to this change, it was not possible to build the release
packaging without the release engineering PGP key, which is nicely
paranoid but ignores the possibility that people other than the
release engineer might want to reuse our packaging. Doh.
So we still use the release engineering key to sign the manifest in
the firmware tarball if the key is available, but if it's not we
produce an unsigned manifest.
|
|
|
|
We don't really need PyCrypto for most things, and installing it on
the fly is easy with apt-get, but it's not worth trying to explain why
it's always included on OSX and has to be installed manually on Linux.
|
|
Python package dependencies in Homebrew packages are tricky enough
that it's easiest just to install PyCrypto unconditionally on OSX.
|
|
|
|
Homebrew reserves the right to decide on the fly which copy of the
Python 2.7 interpreter (Apple's or Homebrew's) we should be using.
This is mostly reasonable, but makes it tricky when a Homebrew package
includes both a Python "application" and Python "bindings", because
the bindings may be installed where the script doesn't see them. So
we symlink the bindings into the application's private library tree,
just as if the bindings were a third-party library our application
needed. Silly, but it works (this week).
|
|
|
|
scripts/build-*.py were treating --conflicts as a sequence of
arguments while Makefile was treating as a single argument whose value
might contain whitespace. No big deal either way for the scripts, and
Makefile is complicated enough, so go with Makefile's approach.
Add some pedantic quoting to Makefile while we're at this, out of
general paranoia and because the inconsistencies were puzzling.
|
|
|
|
* Drop dependency on SQLite3;
* Add dependency on Tornado;
* Use setup.py to install our own Python code;
* Document the Python voodoo better, well, differently.
|
|
No longer depends on sqlite3.
Does now depend on python-tornado: on some platforms (Debian Jessie)
this may need to come from backports.
|
|
|
|
|
|
Apparently Homebrew expects the formula class name to match the name
of the recipe, and gets tetchy when they do not. Minimal fix, wires
in assumptions about how we punctuate package names, but simple and
should suffice for now.
While we were at this, changed argument parsing for
build-homebrew-formula.py to use named (--foo) rather than positional
arguments.
|
|
Get conflict indentation right in generated Homebrew formula.
Consider remote branches as well as local ones when constructing
conflict list, so that we don't omit a conflicting package just
because we've never checked it out in this build tree.
|
|
|
|
We want to be able to provide packaged builds of development branches.
The most straightforward way to do this is a 1:1 correspondence
between branches in the releng tree and variant package names.
We adopt a simple convention: the base package name corresponds to the
master branch, all other branches are named with the base package name
followed by the branch name. So the master branch is the
cryptech-alpha package, the ksng branch is the cryptech-alpha-ksng
branch, and so forth. This isn't a perfect solution, but it's
probably good enough.
In order to do this, we need to generate the debian/control file at
build-time, so that we can generate the list of conflicting packages.
This commit also pulls in a few changes that had collected on the
master branches of various repositories, chiefly because a few of them
were necessary to get it the build to run at all.
|
