HHVM
| Wikimedia infrastructure |
|---|
|
|
Packaging
Adding patches
Any patch you add should be in the DEP-3 format, in debian/patches. It should be added to debian/patches/series in the wikimedia-specific section.
Upgrade HHVM to a new upstream version
Upgrading our packages to a new HHVM version is usually a painful and long process if you're moving between major versions (so 3.3.x => 3.6.x), not so much if you're moving between minor versions. The formal process to follow is however exactly the same in the two cases.
- Clone both our repository and facebook's HHVM one
- In the facebook repo, don't forget to update - recursively - the submodules
- See inside hhvm/third-party, where there is a lot of third-party software, most of which is already packaged in debian and should not be used during compilation. Just remove everything that's not needed from here (see our own repository about this).
- create a tar (excluding the .git directories) of the upstream repository at the tag you want, and name it hhvm-orig_<upstream_version>+dfsg1
- Use git import-orig to import it into the repository. I'd advise you to avoid merging automatically as it can get ugly.
- Try to build the package, rinse, repeat. If you test building anywhere else than a machine with pbuilder, do a fresh clone before compilation; the hhvm build process is messy and it trashes and fiddles with a /lot/ of files. After one compilation, just throw away that clone.
Rebuild the packages
Once you have the repository set up, and you created your own patch, it's pretty easy to build a new package:
on any server that has the puppet role package::builder (at the moment, it's copper in production) you can simply clone the repository, check out both the master and upstream repositories, and build your package:
git checkout upstream
git checkout master
GIT_PBUILDER_AUTOCONF=no DIST=jessie WIKIMEDIA=yes git-buildpackage -us -uc --git-builder=git-pbuilder
Once you did this, you need to upload the package to Reprepro and start deployment. Typically, this is done as follows:
- Deploy to the beta cluster (deployment-prep)
- After 2-3 business days, deploy to production only on the canary appservers and api appservers
- After another 2-3 business days, deploy cluster-wide
Of course, check carefully the logs and metrics - including crashes, and most importantly log in the SAL everything you do.