Merge branch 'master' into validity-in-stackage

.travis.yml

@@ -11,7 +11,7 @@ addons:
     - libgmp-dev
 
 env:
-- GHCVER=8.0.1
+- GHCVER=8.0.2
 
 install:
  # Download and unpack the stack executable

CURATORS.md

@@ -23,8 +23,10 @@ process works:
 
 The typical story on pull requests is: If Travis accepts it and the
 author only added packages under his/her own name, merge it.  If the
-build later fails (see "Adding Debian packages for required system tools or libraries"),
-then block the package until it's fixed.
+build later fails (see [Adding Debian packages]), then block the
+package until it's fixed.
+
+[Adding Debian packages]: https://github.com/fpco/stackage/blob/master/CURATORS.md#adding-debian-packages-for-required-system-tools-or-libraries
 
 If benchmarks, haddocks, or test suites fails at this point we
 typically also block the package until these issues are fixed. This in
@@ -177,8 +179,14 @@ the maintainers of those packages.
 
 ### Adding Debian packages for required system tools or libraries
 Additional (non-Haskell) system libraries or tools should be added to `stackage/debian-bootstrap.sh`.
-Committing the changes to a branch should trigger a DockerHub. Normally only the `nightly` branch needs to be updated
-since new packages are not added to the current lts release.
+After you've committed those changes, merging them into the `nightly` branch should
+trigger a DockerHub build. Simply run:
+
+```bash
+    $ git checkout nightly
+    $ git merge master
+    $ git push
+```
 
 Use [Ubuntu Package content search](http://packages.ubuntu.com/) to determine which package provides particular dev files (it defaults to xenial which is the version used to build Nightly).
 
@@ -337,3 +345,24 @@ errors for builds, tests and benchmarks.
 
 1. Add public ssh key to `~/.ssh/authorized_keys` on build server
 2. Add to fpco/stackage project.
+
+## Dealing with a new GHC release
+
+As mentioned in the [GHC upgrade note], the major impact of a new GHC release
+is on the packages that are causing upper bounds to be put in place. In order
+to minimise out-of-date breakage and allow maintainers to have a solid chance
+of getting their packages into the newest LTS, we try to do the following:
+
+Make an early announcement (in the form of a blog post, typically) of the new
+GHC release on the nightly build and the planned deadline for the new LTS release.
+Make it clear, that in the time coming up to this, we hope package maintainers
+will upgrade their packages to allow for the new GHC release.
+
+We prefer to prune packages causing upper bounds constraints **after** the LTS
+release to allow the maximum amount of packages to get into the newest LTS.
+
+After the first LTS release, the package pruning process may begin in the
+nightly build in order to move forward with getting the latest versions of
+packages compatible with the new GHC release.
+
+[GHC upgrade note]: https://github.com/fpco/stackage/blob/master/MAINTAINERS.md#upgrading-to-a-new-ghc-version

Dockerfile

@@ -2,7 +2,7 @@ FROM fpco/pid1:16.04
 
 ENV HOME /home/stackage
 ENV LANG en_US.UTF-8
-ENV PATH /opt/ghc/8.0.1/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ENV PATH /opt/ghc/8.0.2/bin:/usr/sbin:/usr/bin:/sbin:/bin
 
 ADD debian-bootstrap.sh /tmp/debian-bootstrap.sh
 RUN /tmp/debian-bootstrap.sh && rm /tmp/debian-bootstrap.sh

MAINTAINERS.md

@@ -24,7 +24,7 @@ After doing that, send a pull request (with a commit message like "add foo-bar")
 If you want to make sure that the package builds against the newest versions of all dependecies you can do this:
 ```
 $ cabal update
-$ ghc --version # Should give v8.0.1
+$ ghc --version # Should give v8.0.2
 $ cabal get PACKAGE-VERSION # e.g. aeson-0.11.2.1
 $ cd PACKAGE-VERSION
 $ cabal sandbox init # Should give "Creating a new sandbox" and not "Using an existing sandbox".

README.md

@@ -84,3 +84,42 @@ The following describes at a high level the series of steps for processing
 1. Load up most recent build plan
 2. Convert build plan into constraints for next build
 3. Continue from step (3) above
+
+Frequently Asked Questions
+--------------------------
+
+__Why does Stackage have an older version of a package than Hackage?__
+
+There are a number of answers to this question:
+
+* Simplest reason: how old of a Stackage snapshot are you using? Once a
+  snapshot is created, it's frozen for all time. So if you use
+  nightly-2016-01-01, by the time you get to 2018, it will be pretty dated.
+* If you're using an LTS snapshot: we lock down major versions when
+  first creating an LTS run, so subsequent minor versions will not get
+  new versions necessary. For example, if LTS 6.0 has `foo` version
+  1.2.3, and the author immediately thereafter releases a version
+  1.3.0 and never releases another 1.2.\* version, you'll never get
+  another update in the LTS 6 line
+* Sometimes we have upper bounds in place because other packages have
+  problems with newer versions of dependencies. Open up the
+  [build-constraints file](https://github.com/fpco/stackage/blob/master/build-constraints.yaml)
+  and search for "Stackage upper bounds"
+* Wired-in packages - those that ship with GHC and cannot be upgraded,
+  and packages depending on them - are fixed to GHC versions. Common
+  examples of this are containers and transformers. There's a lot more
+  information on this in
+  [an FP Complete blog post](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)
+
+__How long do you maintain an LTS build?__
+
+We only guarantee that we will maintain a single LTS major version at
+a time, and that it will be maintained for at least three months. This
+is the
+[originally proposed support window](https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixes),
+and hasn't changed since then.
+
+That said, we do maintain the capability to keep multiple LTS runs
+operational in parallel, and with LTS 6 and 7 in fact did so. We
+aren't changing our guarantees yet on longevity of a release, but are
+trying to push out the bounds a bit farther.

automated/build.sh

@@ -121,7 +121,7 @@ docker run $ARGS_PREBUILD $IMAGE /bin/bash -c "stackage-curator check --plan-fil
 # Now do the actual build. We need to first set the owner of the home directory
 # correctly, so we run the command as root, change owner, and then use sudo to
 # switch back to the current user
-docker run $ARGS_BUILD $IMAGE /bin/bash -c "chown $USER $HOME && exec sudo -E -u $USER env \"HOME=$HOME\" \"PATH=\$PATH\" stackage-curator make-bundle --plan-file $PLAN_FILE --docmap-file $DOCMAP_FILE --bundle-file $BUNDLE_FILE --target $TARGET"
+docker run $ARGS_BUILD $IMAGE nice -n 15 /bin/bash -c "chown $USER $HOME && exec sudo -E -u $USER env \"HOME=$HOME\" \"PATH=\$PATH\" stackage-curator make-bundle --jobs 4 --plan-file $PLAN_FILE --docmap-file $DOCMAP_FILE --bundle-file $BUNDLE_FILE --target $TARGET"
 
 # Make sure we actually need this snapshot. We used to perform this check
 # exclusively before building. Now we perform it after as well for the case of

check

@@ -3,4 +3,4 @@
 # Convenience script for checking constraints locally
 
 cd `dirname $0`
-exec stack exec --resolver ghc-8.0.1 stackage-curator check
+exec stack exec --resolver ghc-8.0.2 stackage-curator check

debian-bootstrap.sh

@@ -25,7 +25,7 @@ add-apt-repository -y ppa:marutter/rrutter
 #add-apt-repository -y ppa:openstack-ubuntu-testing/icehouse
 
 # Set the GHC version
-GHCVER=8.0.1
+GHCVER=8.0.2
 
 # Get Stack
 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 575159689BEFB442
@@ -43,6 +43,7 @@ apt-get install -y \
     curl \
     freeglut3-dev \
     git \
+    gradle \
     libadns1-dev \
     libaio1 \
     libalut-dev \
@@ -92,6 +93,10 @@ apt-get install -y \
     libpcap0.8-dev \
     libpq-dev \
     libsdl2-dev \
+    libsdl2-mixer-dev \
+    libsdl2-image-dev \
+    libsdl2-gfx-dev \
+    libsdl2-ttf-dev \
     libsnappy-dev \
     libsndfile1-dev \
     libsqlite3-dev \