aboutsummaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)Author
2020-07-12More fun with str and bytesRob Austein
2020-07-12Syntax change for octal constants, sighRob Austein
2020-07-12Attempt to go Python3-onlyRob Austein
Ubuntu 20.04 no longer really supports Python 2, so we'd have to fork the packaging code if we wanted to keep support for Python 2 elsewhere. Given that Python 3 has been around for a more than a decade and that Python 2 was formally EOLed more than six months ago as of this writing, this seems like an unnecessary complication. The biggest change is rewriting the Homebrew formula for Python 3.
2020-06-21Typo in updated build scriptRob Austein
2020-06-21Preliminary support for Python 3Rob Austein
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.
2020-06-21Allow build of firmware package without release engineering keyRob Austein
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.
2017-09-21Fix syntax of generated Debian control file.Rob Austein
2017-06-08Add PyCrypto dependency on Debian and Ubuntu too.Rob Austein
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.
2017-06-08Add PyCrypto to package dependencies on OSX.Rob Austein
Python package dependencies in Homebrew packages are tricky enough that it's easiest just to install PyCrypto unconditionally on OSX.
2017-06-08Clean up MANIFEST commit data.Rob Austein
2017-05-20Better Homebrew fix: Just symlink our bindings into our vendor tree.Rob Austein
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).
2017-05-20Scripts need to use same version of Python as libraries.Rob Austein
2017-05-11Fix --conflicts inconsistency between build scripts and Makefile.Rob Austein
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.
2017-05-10Homebrew wants transitive closure of our Python dependencies.Rob Austein
2017-04-15Update Homebrew formula.Rob Austein
* Drop dependency on SQLite3; * Add dependency on Tornado; * Use setup.py to install our own Python code; * Document the Python voodoo better, well, differently.
2017-04-14Update Debian package dependencies.Rob Austein
No longer depends on sqlite3. Does now depend on python-tornado: on some platforms (Debian Jessie) this may need to come from backports.
2017-04-14Might work better if we were to write emit Python.Rob Austein
2017-04-14First cut at a setup.py for our Python code.Rob Austein
2016-12-14Fix Homebrew formula class name.Rob Austein
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.
2016-12-14Minor tweaks to branch-based package conflict hacks.Rob Austein
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.
2016-12-14Oops, need to generate right binary package name too.Rob Austein
2016-12-14Support multiple packages corresponding to multiple releng branches.Rob Austein
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.