Switch packaging release checksum to sha512

For our releases we will now be using .sha512 files rather than .sha files
containing sha1 checksums. This change is triggered by a recent update of
the Apache Release Distribution Policy.

Please see this mail for details:

```
Hi PMC,

    The Release Distribution Policy[1] changed regarding .sha files.
    See under "Cryptographic Signatures and Checksums Requirements" [2].

   Old policy :

     -- use extension .sha for any SHA checksum (SHA-1, SHA-256, SHA-512)

   New policy :

      -- use .sha1 for a SHA-1 checksum
      -- use .sha256 for a SHA-256 checksum
      -- use .sha512 for a SHA-512 checksum
      -- [*] .sha should contain a SHA-1

   Why this change ?

      -- Verifying a checksum under the old policy is/was not handy.
         You have to inspect the .sha to find out which algorithm
         should be used ; or try them all (SHA-1, SHA256, etc).
         The new scheme avoids this ambiguity.
      -- The last point[*] was only added for clarity. Most of the
         old, stale .sha's contain a SHA-1. The relatively new .sha's
         contain a SHA-512. The expectation is that the last catagory will
         disappear, when active projects adapt to the 'new' convention.

   Impact :

      -- Should be none ; many projects already use the 'new' convention.
      -- Please ask your release managers to use .sha1, .sha256, .sha512
         instead of the .sha extension.
      -- Please fix your build-tools if you have any.

   Piggyback :

      -- The policy requires a .md5 for every package ;
         providing a .sha512 is recommended.
         Since MD5 is essentially broken, it is to be expected that
         in the future a .sha512 will be required.
         Perhaps it is wize to start providing .sha512's
         with your releases if you do not already do so.

      -- Visit http://mirror-vm.apache.org/checker/
         to check the health of your /dist/-area ;
         my stuff ; any feedback is most welcome.

   Thanks ; regards,

   Henk Penning

    [1] http://www.apache.org/dev/release-distribution
    [2] http://www.apache.org/dev/release-distribution#sigs-and-sums
```

Reviewed at https://reviews.apache.org/r/62831/
1 file changed
tree: 2efe1a77545ea3e44a850fbdf82a0bbbf8ae591e
  1. build-support/
  2. builder/
  3. docs/
  4. specs/
  5. test/
  6. .gitignore
  7. .reviewboardrc
  8. build-artifact.sh
  9. rbt
  10. README.md
README.md

Packaging for Apache Aurora

This repository maintains configuration and tooling for building binary distributions of Apache Aurora.

Building a binary

Binaries are built within Docker containers that provide the appropriate build environment for the target platform. You will need to have a working Docker installation before proceeding.

  1. Fetch a source distribution, such as an official one. Alternatively, you can also build from an arbitrary git commit by instead preparing sources from the Aurora source repository:

     git archive --prefix=apache-aurora-$(cat .auroraversion)/ -o snapshot.tar.gz HEAD
    
  2. Run the builder script, providing the distribution platform and the source distribution archive you downloaded in (1). The example below will build Aurora 0.9.0 debs for Ubuntu Trusty.

     ./build-artifact.sh builder/deb/ubuntu-trusty \
       ../apache-aurora-0.9.0.tar.gz \
       0.9.0
    

When this completes, debs will be placed in artifacts/aurora-ubuntu-trusty/dist/.

Creating a release candidate

Release candidates are hashed and signed binaries that are uploaded to bintray for easy access and testing by voters. You will need to have a bintray account and a generic repo created for the purpose of uploading the release candidate binaries in order to proceed.

Cut a branch and build the binaries

The example below is for the 0.12.0 release where upstream is https://git-wip-us.apache.org/repos/asf/aurora-packaging:

git checkout -b 0.12.x upstream/master

Now run the Building a binary procedure detailed above.

Hash, sign and upload the binaries

Run the following which will create a tarball for each distribution platform that can be uploaded to bintray:

N.B.: the release-candidate script requires bash 4.x or higher.

./build-support/release/release-candidate
Signing artifacts for centos-7...
Created archive for centos-7 artifacts at /home/jsirois/dev/aurora/jsirois-aurora-packaging/artifacts/aurora-centos-7/dist/rpmbuild/RPMS/upload.tar.
Signing artifacts for debian-jessie...
Created archive for debian-jessie artifacts at /home/jsirois/dev/aurora/jsirois-aurora-packaging/artifacts/aurora-debian-jessie/upload.tar.
Signing artifacts for ubuntu-trusty...
Created archive for ubuntu-trusty artifacts at /home/jsirois/dev/aurora/jsirois-aurora-packaging/artifacts/aurora-ubuntu-trusty/upload.tar.
All artifacts prepared for upload to bintray.

In the bintray UI, create a new version in your release-candidate repo, for example ‘0.12.0’. Then, in the version UI you can upload the artifacts. Bintray theoretically supports exploding tarballs on upload, but currently this functionality does not work (it fails to detect tarballs as explodable artifacts or, if it does, it tries to sign the artifacts, but fails due to a signature already being present, even when signing is disabled at the repo level).

This is all to say, it's easier to just un-tar the various upload.tar files and upload their contents directly. This can be accomplished by dragging and dropping all files into the upload UI for the version you created.

Finally, ‘publish’ the results.

bintray publish

Adding a new distribution platform

There are only two requirements for a ‘builder’ to satisfy:

  • a Dockerfile to provide the repeatable build environment
  • a build.sh script that creates artifacts

Please see the makeup of other builders for examples.