| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Developer consensus is that between mulitple new cores and a number of
performance improvements, this is worthy of a major version number bump.
|
|
|
|
|
|
|
|
|
|
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.
|
|
NB: this change is not by itself enough to prep the build environment
for new platforms, one must also (manually):
a) Update the conf/distributions files in the reprepro repositories to
include the new codenames;
b) Install an updated version of the debootstrap package on the build
machine so that it knows how to construct the base environment for
the new codenames; and
c) Create the initial pbuilder environments fot the new codenames
using `pbuilder-dist create`.
There may be other steps I've forgotten, it's been a while since we
last added a new codename.
Per recommendation in the Debian Wiki, the debootstrap package I
expect to use for this was manually backported (so that our existing
build machine can know how to build for codenames newer than what the
build machine itself is running). In this case I'm using the
stretch-backports version (to get Ubuntu Bionic).
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the long run, once this stablizes into a normal set of Debian
packages with human maintainer(s), this business of constructing the
package changelog automatically will go away, but as long as we're
automating this, we need to be consistant in our automation.
|
|
build process cleanup.
|
|
new one.
Original design intent was that the build tree be created once then
left alone, but this turns out to be short-sighted: we really don't
want to have to re-synthesize all of the Verilog code just because
somebody added a new C file to the firmware.
|
|
Homebrew yet.
|
|
Undoubtedly doesn't work yet, and still needs doc, but perhaps now
ready for testing on build machine.
|
