Augie Fackler <augie@google.com> [Wed, 06 May 2015 13:15:39 -0400] rev 24973
dockerdeb: rules to build a debian package using docker
Currently only supports jessie (current stable), but other version
should be trivial.
Augie Fackler <augie@google.com> [Thu, 07 May 2015 10:28:58 -0400] rev 24972
packaging: extract packagelib for common code from builddeb and buildrpm
Augie Fackler <augie@google.com> [Wed, 06 May 2015 13:13:54 -0400] rev 24971
builddeb: new script for building a deb package
Future work will allow us to use docker to build debs.
Right now this doesn't install any config files. I plan to do that as
a followup, but getting something basic and working checked in seems
like more of a priority than getting everything done in one big step.
This also does not create a source deb yet. I haven't looked into that
process.
Note that this declares incompatibility with the `mercurial-common`
package. It's typical for debian packages to be split between
architecture-independent bits and native bits, meaning the python bits
downstream live in mercurial-common and the c extension bits live in
mercurial. We don't do that because we want to (ideally) give users a
single deb file to install.
Augie Fackler <augie@google.com> [Wed, 06 May 2015 14:36:17 -0400] rev 24970
dockerlib: fix initcontainer for boot2docker users
This allows me to build rpm packages using boot2docker on my Mac. It's
probably a very fragile hack, but it seems to work well enough for now
that I felt it was worth sharing.
Augie Fackler <augie@google.com> [Wed, 06 May 2015 10:45:51 -0400] rev 24969
dockerlib: extract initcontainer() method
This helps contain all the logic around creating containers.
Augie Fackler <augie@google.com> [Wed, 06 May 2015 10:45:07 -0400] rev 24968
dockerlib: start extracting common functions for setting up docker
I'm about to start interacting with docker for Debian packaging too,
so it's time to centralize this so that any bugfixes I figure out
apply to both codepaths.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 07 May 2015 17:14:00 -0700] rev 24967
run-test: ensure the test ports are available before launching test
I'm running into a systematic issue because there is always some port taken in the
1500-wide range of ports used by the test (3 for each test file).