aboutsummaryrefslogtreecommitdiff
path: root/source/debian
AgeCommit message (Collapse)Author
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-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.
2018-06-17Packaging voodoo to support same code version on multiple releases.Rob Austein
reprepro strictly follows the Debian package rule that two package files which have the same name must have identical content. Which is fine, except when we want to support the same version of a package on multiple releases of the same Debian-flavored operating system. The usual hack for this is to add a release-specific tag to the end of the version string. The brute force way of doing this requires modifying the source package for each release, but there's an obscure hack which lets us augment the binary package versions directly.
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.
2016-08-10Whole bunch of improvements to Debian packaging from Ondrej Sury (thanks!).Rob Austein
2016-07-05Add python-serial to runtime dependencies.Rob Austein
2016-06-27First cut at consolidated alpha releng.Rob Austein
Undoubtedly doesn't work yet, and still needs doc, but perhaps now ready for testing on build machine.