haskell/stackage
1
0
Fork 0
mirror of https://github.com/commercialhaskell/stackage.git synced 2026-01-12 23:38:29 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge branch 'master' of github.com:fpco/stackage

Browse Source
This commit is contained in:
Athan Clark 2016-02-18 09:42:33 -07:00
commit b96f361caa
10 changed files with 792 additions and 333 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -3,3 +3,4 @@
nightly-*.yaml
lts-*.yaml
*.swp
check-plan.yaml

31
.travis.yml
View File

@ -1,27 +1,40 @@
# Use new container infrastructure to enable caching
sudo: false
language: haskell
# Choose a lightweight base image; we provide our own build tools.
language: c
# GHC depends on GMP. You can add other dependencies here as well.
addons:
apt:
packages:
- libgmp-dev
env:
- GHCVER=7.10.3
install:
# Download and unpack the stack executable
- mkdir -p ~/.local/bin
- export PATH=$HOME/.local/bin:$PATH
- travis_retry curl -L https://www.stackage.org/stack/linux-x86_64 | tar xz --wildcards --strip-components=1 -C ~/.local/bin '*/stack'
# Get stackage-curator
- wget https://s3.amazonaws.com/stackage-travis/stackage-curator/stackage-curator.bz2
- bunzip2 stackage-curator.bz2
- chmod +x stackage-curator
# Get stack
- travis_retry curl -L https://github.com/commercialhaskell/stack/releases/download/v0.1.3.0/stack-0.1.3.0-x86_64-linux-gmp4.gz | gunzip > stack
- chmod +x stack
- mv stackage-curator ~/.local/bin
# Install GHC and cabal-install
- ./stack setup 7.10.2
- ./stack --resolver ghc-7.10 build stackage-update
- stack setup $GHCVER
# Update the index
- travis_retry ./stack --resolver ghc-7.10 exec stackage-update
- travis_retry stack update
script:
- ./stack --resolver ghc-7.10 exec ./stackage-curator check
- stack --resolver ghc-$GHCVER exec stackage-curator check
cache:
directories:
- $HOME/.stack
- $HOME/.stackage/curator/cache

40
CURATORS.md
View File

@ -1,9 +1,8 @@
This is a collection of instructions for what Stackage curators- the guys who
maintain the Stackage project itself- should be doing on a regular basis. At
the time of writing (July 2015), this is handled almost entirely by Michael
Snoyman. Curation activities are mostly automated, and do not take up a
significant amount of time. But it's good to spread the knowledge for obvious
reasons (errant buses, if I ever decide to take a vacation...).
This is a collection of instructions covering the processes that the Stackage curators - the
guys who maintain the Stackage project itself - should be doing on a regular basis.
Originally this was handled largely by Michael Snoyman,
but now we are a team of 4 people handling requests weekly in rotation.
Curation activities are mostly automated, and do not take up a significant amount of time.
## Workflow
@ -18,7 +17,7 @@ process works:
* The stackage-build server (described below) is able to run automated builds using the [build.sh script](https://github.com/fpco/stackage/blob/master/automated/build.sh)
* When a new Nightly build is completed, it is uploaded to [the nightly repo](https://github.com/fpco/stackage-nightly)
* Once a week, we run an LTS minor bump. Instead of using build-constraints.yaml, that job takes the previous LTS release, turns it into constraints, and then bumps the version numbers to the latest on Hackage, in accordance with the version bounds in the build plan. This plans are uploaded to [the LTS repo](https://github.com/fpco/lts-haskell)
* Cutting a new LTS major release is essentially just a Stackage Nightly that gets uploaded as an LTS
* Cutting a new LTS major release is essentially just a Stackage Nightly that gets rebuilt and uploaded as an LTS
## Pull requests
@ -42,7 +41,7 @@ to refer to the issue for workarounds added to that file.
### 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 should trigger a DockerHub. Normally only the master branch needs to be updated
Committing the changes should trigger a DockerHub. Normally only the nightly branch needs to be updated
since new packages are not added to the current lts release.
Use [Ubuntu Package content search](http://packages.ubuntu.com/) to determine which package provides particular dev files (it defaults to trusty which is the same version as the server).
@ -50,7 +49,11 @@ Use [Ubuntu Package content search](http://packages.ubuntu.com/) to determine wh
### Upgrading GHC version
The Dockerfile contains information on which GHC versions should be used. You
can modify it and push it to Github to trigger a DockerHub build. The master
branch is used for nightlies, and the lts branch for LTS.
branch is used for nightlies. For LTSes, we use the ltsX branch, where X is the
major version number (e.g., lts3 for lts-3.\*).
Note that when starting a new LTS major release, you'll need to modify Docker
Hub to create a new Docker tag for the relevant branch name.
### Getting the new image to the build server
Once a new Docker image is available, you'll need to pull it onto the stackage-build server (see
@ -77,6 +80,8 @@ Host stackage-build
Hostname ec2-52-5-20-252.compute-1.amazonaws.com
```
### Running the build script
We currently run the builds manually so make it easy to see when there are
bounds issues that need to be corrected. Automated this would be even better,
we're just not there yet.
@ -101,6 +106,13 @@ info above). For an LTS minor bump, you'll typically want to use the
CONSTRAINTS='--constraint "conduit < 1.4.5" --constraint "criterion < 1.2.3"' /opt/stackage-build/stackage/automated/build.sh lts-2.17
```
Valid arguments to include in this environment variable:
* `--constraint` to modify an upper or lower bound
* `--add-package` to add a brand new package
* `--expect-test-failure` to expect tests to fail
* `--expect-haddock-failure` to expect haddocks to fail
If a build fails for bounds reasons, see all of the advice above. If the code
itself doesn't build, or tests fail, open up an issue and then either put in a
version bound to avoid that version or something else. It's difficult to give
@ -116,3 +128,13 @@ build succeeds, write something like `sleep 20h;
/opt/stackage-build/stackage/automated/build.sh nightly-2015-01-02`.)
LTS minor bumps typically are run on Sundays.
### Website sync debugging (and other out of disk space errors)
* You can detect the problem by running `df`. If you see that `/` is out of space, we have a problem
* There are many temp files inside `/home/ubuntu/stackage-server-cron` that can be cleared out occasionally
* You can then manually run `/home/ubuntu/stackage-server-cron.sh`, or wait for the cron job to do it
### Wiping the cache
Sometimes the cache can get corrupted which might manifest as `can't load .so/.DLL`. You can wipe the nightly cache and rebuild everything by doing `rm -rf /opt/stackage-build/stackage/automated/nightly`.

21
Dockerfile
View File

@ -2,24 +2,7 @@ FROM ubuntu:14.04
ENV HOME /home/stackage
ENV LANG en_US.UTF-8
RUN mkdir /home/stackage -p
RUN locale-gen en_US.UTF-8
RUN DEBIAN_FRONTEND=noninteractive apt-get update
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y software-properties-common python-software-properties git
RUN DEBIAN_FRONTEND=noninteractive add-apt-repository ppa:hvr/ghc -y
ENV PATH /opt/ghc/7.10.3/bin:/usr/sbin:/usr/bin:/sbin:/bin
ADD debian-bootstrap.sh /tmp/debian-bootstrap.sh
RUN DEBIAN_FRONTEND=noninteractive bash /tmp/debian-bootstrap.sh
RUN rm /tmp/debian-bootstrap.sh
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y cabal-install-1.22 ghc-7.10.2 ghc-7.10.2-htmldocs alex-3.1.3 happy-1.19.4 sudo
ENV PATH /home/stackage/.cabal/bin:/usr/local/sbin:/usr/local/bin:/opt/ghc/7.10.2/bin:/opt/cabal/1.22/bin:/opt/alex/3.1.3/bin:/opt/happy/1.19.4/bin:/usr/sbin:/usr/bin:/sbin:/bin
RUN cabal update
RUN cabal install hscolour cabal-install && cp $HOME/.cabal/bin/* /usr/local/bin && rm -rf $HOME/.cabal $HOME/.ghc /tmp/stackage
RUN wget https://s3.amazonaws.com/stackage-travis/stackage-curator/stackage-curator.bz2 && bunzip2 stackage-curator.bz2 && chmod +x stackage-curator && mv stackage-curator /usr/local/bin
# Get new hyperlinked Haddocks
RUN mkdir -p /opt/haddock && cd /opt/haddock && wget https://s3.amazonaws.com/download.fpcomplete.com/michael/haddock-2.16.2.tar.gz && tar zxf haddock-2.16.2.tar.gz && rm -f /opt/ghc/7.10.2/bin/haddock && ln -s /opt/haddock/2.16.2/bin/haddock /opt/ghc/7.10.2/bin/haddock
RUN /tmp/debian-bootstrap.sh && rm /tmp/debian-bootstrap.sh

73
MAINTAINERS.md Normal file
View File

@ -0,0 +1,73 @@
This project is built around the concept of maintainers taking responsibility for making their packages work with the rest of the stable ecosystem, usually meaning the newest version of all dependencies. This is a social contract, and is not reflected in the codebase in any way.
The idea behind Stackage is that, if all packages work with the newest versions of dependencies, we avoid dependency hell. Specifically, we aim for:
* All packages are buildable and testable from Hackage. We recommend [the Stack Travis script](http://docs.haskellstack.org/en/stable/GUIDE.html#travis-with-caching), which ensures a package is not accidentally incomplete.
* All packages are compatible with the newest versions of all dependencies.
* All packages are compatible with the versions of libraries that ship with GHC ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
## Adding a package
Anyone can add a package to Stackage, but it's highly encouraged that the actual package maintainer is also the Stackage maintainer. If that is not the case, you should drop the package maintainer a note first.
To add your package, first fork this repository.
In the [`build-constraints.yaml`](https://github.com/fpco/stackage/blob/master/build-constraints.yaml) file, there's a section called `packages`.
To add a set of packages, you would add:
"My Name myemail@example.com @mygithubuser":
- package1
- package2
- package3
After doing that, send a pull request (with a commit message like "add foo-bar"). We do not require new submissions to be tested against the rest of Stackage before the pull request (though it is a good idea to do so if you can with `stack --resolver nightly exec stackage-curator check` and `stack --resolver nightly build`), provided you meet the dependency version requirements above. If your library depends on a C library, add a note to your pull request with the Ubuntu library name, or even better edit the `debian-bootstrap.sh` script directly
**NB** Please use commit messages like "add foo-bar" or "add johndev's packages"
(`build-constraints.yaml` is the most frequently changed file in this git repo
so commit messages like "update build-constraints.yaml" are not helpful).
**NB2** There can be a delay of up to an hour before package versions newly
uploaded to Hackage appear to our build server. If you just uploaded a package
to Hackage that you're trying to get included, we recommend waiting an hour
before opening the PR.
## Uploading a new package
When a new version of a package is uploaded to Hackage, we automatically try to include it in Stackage (unless the new version is considered experimental). That can result in a number of possible failures. If there is a failure we temporarily introduce an upper bound, and raise GitHub issue tickets to resolve the issue.
If the new version doesn't compile then the package author should quickly (within 1 week) upload a fixed version.
If a package's test suite is failing, the first job is to investigate why. If this is due to a bad interaction with versions of other packages in Stackage, then it is the responsibility of the maintainer to fix the test suite. In some situations, it is acceptable to not run the test suite.
## Following dependency upgrades
If a new version of a dependency is released, and that stops your package compiling/passing the tests, then it is your responsibility to modify your package. It is highly recommended that all package maintainers follow the dependencies of their packages on [Packdeps](http://packdeps.haskellers.com/), typically using the RSS feeds.
**If restrictive version bounds are the only problem** then you must quickly (within 1 week) upload a new version with relaxed version bounds. Note that unlike the PVP, Stackage does not require upper bounds.
**If the new dependency causes breaking changes** then all package authors should quickly assess the likely impact on their package (within 1 week) and then produce a new compatible version. The expected timeline for new versions varies between 1 week and 1 month, depending on the significance of the change, and thus the work required to produce those new versions.
## Failing to meet the time limits
Maintainers are humans, humans get sick/have babies/go on holiday. If you have regular problems meeting the limits, find a co-maintainer. If you have a one-off problem, respond to the GitHub tickets saying so, and some kind soul might pick up the slack.
The time limits are intended to stop people being inconvenienced because of problems in other packages. Where such inconvenience happens, we will drop the offending packages from Stackage. While upper bounds are sometimes a temporary solution, they are against the ethos of Stackage, so will not be kept for long.
## Adding a package to an LTS snapshot
The steps above affect the Stackage Nightly builds, but do not directly affect
LTS Haskell builds. When we build a new LTS Haskell major version (anything
ending in `.0`), the package set is taken from Stackage Nightly. Therefore, by
following the above steps, you can get your package into the next major LTS
Haskell release.
If you would like to get your package added to an existing LTS Haskell major
release (e.g., if `lts-3.21` is out, you would want your package to appear in
`lts-3.22`), please do the following in addition to the steps above:
* Open up a new issue on the [lts-haskell repo](https://github.com/fpco/lts-haskell/issues/new)
* Specify the LTS major version you would like your package to go into (e.g., lts-3)
* Provide a list of packages you would like added, and if relevant, any upper bounds on those packages
* Be patient! The LTS releases are by their nature more conservative than nightly, and therefore adding new packages is a more manual process. The Stackage curators will try to get to your issue quickly, but there may be some delay.

87
README.md
View File

@ -4,10 +4,27 @@ stackage
[![Build Status](https://travis-ci.org/fpco/stackage.svg?branch=master)](https://travis-ci.org/fpco/stackage)
"Stable Hackage": creating a vetted set of packages from Hackage.
This repository is for package authors and maintainers to get their packages into Stackage.
If you simply want to use Stackage as an end user, please follow the instructions on [https://www.stackage.org/](https://www.stackage.org).
__NOTE__ This repository is for package authors and maintainers to get their packages into
Stackage. If you simply want to use Stackage as an end user, please follow the
instructions on [http://www.stackage.org/](http://www.stackage.org).
We strongly recommend using the Haskell tool stack for doing builds, which
includes built-in Stackage support: [stack](https://github.com/commercialhaskell/stack) [![Build Status](https://travis-ci.org/commercialhaskell/stack.svg?branch=master)](https://travis-ci.org/commercialhaskell/stack).
Add your package
----------------
We welcome all packages, provided:
* The package author/maintainer agrees to the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md).
* The package is buildable and testable from Hackage. We recommend [the Stack Travis script](http://docs.haskellstack.org/en/stable/GUIDE.html#travis-with-caching), which ensures a package is not accidentally incomplete.
* The package is compatible with the newest versions of all dependencies.
* The package is compatible with the versions of libraries that ship with GHC ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
Full details on how to add a package can be found in the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md#adding-a-package).
Other repos
-----------
The Stackage project consists of multiple repositories. This repository
contains the metadata on packages to be included in future builds and some
@ -19,11 +36,6 @@ project information. In addition, we have the following repositories:
* [lts-haskell](https://github.com/fpco/lts-haskell)
* [stackage-nightly](https://github.com/fpco/stackage-nightly)
We strongly recommend using the Haskell tool stack for doing builds, which
includes built-in Stackage support:
* [stack](https://github.com/commercialhaskell/stack) [![Build Status](https://travis-ci.org/commercialhaskell/stack.svg?branch=master)](https://travis-ci.org/commercialhaskell/stack)
We also support some add-on tools to cabal-install to make its usage with
Stackage both easier and more secure:
@ -33,63 +45,16 @@ Stackage both easier and more secure:
* [stackage-install](https://github.com/fpco/stackage-install) [![Build Status](https://travis-ci.org/fpco/stackage-install.svg?branch=master)](https://travis-ci.org/fpco/stackage-install)
* [stackage-build-plan](https://github.com/fpco/stackage-build-plan) [![Build Status](https://travis-ci.org/fpco/stackage-build-plan.svg?branch=master)](https://travis-ci.org/fpco/stackage-build-plan)
Get your package included
-------------------------
In order to get your package included in the set of stable packages, you should
send a pull request against this repository. In the [`build-constraints.yaml`](https://github.com/fpco/stackage/blob/master/build-constraints.yaml) file,
there's a section called `packages`. In general, to add a set of
packages, you would add:
"My Name myemail@example.com @mygithubuser":
- package1
- package2
- package3
You can follow the examples of the other sets of packages in that function.
Once you've done this, you can send a pull request to get your package
included.
__NOTE__: In order to ease the process of adding new packages, we no longer
require new submissions to be tested on your own system before sending a pull
request. If you believe your package works with the newest versions of all
dependencies, you may send a pull request without testing first.
Please use commit messages like "add foo-bar" or "add johndev's packages"
(`build-constraints.yaml` is the most frequently changed file in this git repo
so commit messages like "update build-constraints.yaml" are not helpful).
You should also read the [maintainers
agreement](https://github.com/fpco/stackage/wiki/Maintainers-Agreement).
Package Author Guidelines
-------------------------
There are some basic rules to get your package to play nice with Stackage. Here
are some quick guidelines to hopefully make this easier:
* Make sure that your code is buildability and testable from Hackage. Often
times, authors test their builds locally, but the tarball that gets uploaded
to Hackage is missing some necessary files. The best way to do this is to
set up a Travis job to do it for you. We recommend the
[multi-ghc-travis](https://github.com/hvr/multi-ghc-travis) approach.
* Make your code compatible with the newest versions of all dependencies.
* Make your code compatible with the versions of libraries that ship with GHC ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
There are certainly many other tips that could be added here. If you think of
any, please send a pull request!
Build the package set
---------------------
Generally, building the package set should be done only by the Jenkins machine
or by the official maintainers, as the process does require quite a bit of
setup on the local machine. That said, you'll likely be able to get a stable
build by running:
cabal update
cabal install stackage
stackage nightly
Generally, building the package set should be done only by the Stackage build
machine by the Stackage curation team. If you're interested in trying this
yourself, please check out [the curator
guide](https://github.com/fpco/stackage/blob/master/CURATORS.md), though be
aware that this is not a recommended practice and there likely will be problems
you will need to debug yourself.
### Docker

54
automated/build.sh
View File

@ -4,7 +4,17 @@ set -eux
ROOT=$(cd $(dirname $0) ; pwd)
TARGET=$1
TAG=$(echo $TARGET | cut -d- -f 1)
# For nightly-YYYY-MM-DD, tag should be nightly
# For lts-X.Y, tag should be ltsX
SHORTNAME=$(echo $TARGET | cut -d- -f 1)
if [ $SHORTNAME = "lts" ]
then
TAG=$(echo $TARGET | sed 's@^lts-\([0-9]*\)\.[0-9]*@lts\1@')
else
TAG=$SHORTNAME
fi
IMAGE=snoyberg/stackage:$TAG
PLAN_FILE=current-plan.yaml
@ -12,16 +22,20 @@ DOCMAP_FILE=current-docmap.yaml
BUNDLE_FILE=current.bundle
CABAL_DIR=$ROOT/cabal
STACK_DIR=$ROOT/stack
GHC_DIR=$ROOT/ghc
DOT_STACKAGE_DIR=$ROOT/dot-stackage
WORKDIR=$ROOT/$TAG/work
SSH_DIR=$ROOT/ssh-$TAG
EXTRA_BIN_DIR=$ROOT/extra-bin
SSH_DIR=$ROOT/ssh-$SHORTNAME
mkdir -p \
"$CABAL_DIR" \
"$STACK_DIR" \
"$GHC_DIR" \
"$DOT_STACKAGE_DIR" \
"$WORKDIR" \
"$EXTRA_BIN_DIR" \
"$SSH_DIR"
GITCONFIG=$ROOT/gitconfig
@ -63,13 +77,35 @@ bunzip2 stackage-curator.bz2
chmod +x stackage-curator
)
ARGS_COMMON="--rm -u $USER -v $WORKDIR:/home/stackage/work -w /home/stackage/work -v $BINDIR/stackage-curator:/usr/local/bin/stackage-curator:ro -v /etc/passwd:/etc/passwd:ro -v /etc/group:/etc/group:ro"
ARGS_PREBUILD="$ARGS_COMMON -v $CABAL_DIR:/home/stackage/.cabal -v $GHC_DIR:/home/stackage/.ghc -v $DOT_STACKAGE_DIR:/home/stackage/.stackage"
ARGS_BUILD="$ARGS_COMMON -v $CABAL_DIR:/home/stackage/.cabal:ro -v $GHC_DIR:/home/stackage/.ghc:ro"
ARGS_UPLOAD="$ARGS_COMMON -e AWS_ACCESS_KEY=$AWS_ACCESS_KEY -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY -e AWS_SECRET_KEY=$AWS_SECRET_KEY -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_KEY -v $AUTH_TOKEN:/auth-token:ro -v $HACKAGE_CREDS:/hackage-creds:ro -v $DOT_STACKAGE_DIR:/home/stackage/.stackage -v $SSH_DIR:/home/ubuntu/.ssh:ro -v $GITCONFIG:/home/stackage/.gitconfig:ro -v $CABAL_DIR:/home/stackage/.cabal:ro"
ARGS_COMMON="--rm -v $WORKDIR:/home/stackage/work -w /home/stackage/work -v $BINDIR/stackage-curator:/usr/bin/stackage-curator:ro -v /etc/passwd:/etc/passwd:ro -v /etc/group:/etc/group:ro -v $EXTRA_BIN_DIR:/home/stackage/bin:ro"
ARGS_PREBUILD="$ARGS_COMMON -u $USER -v $CABAL_DIR:/home/stackage/.cabal -v $STACK_DIR:/home/stackage/.stack -v $GHC_DIR:/home/stackage/.ghc -v $DOT_STACKAGE_DIR:/home/stackage/.stackage"
ARGS_BUILD="$ARGS_COMMON -v $CABAL_DIR:/home/stackage/.cabal:ro -v $STACK_DIR:/home/stackage/.stack:ro -v $GHC_DIR:/home/stackage/.ghc:ro"
ARGS_UPLOAD="$ARGS_COMMON -u $USER -e AWS_ACCESS_KEY=$AWS_ACCESS_KEY -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY -e AWS_SECRET_KEY=$AWS_SECRET_KEY -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_KEY -v $AUTH_TOKEN:/auth-token:ro -v $HACKAGE_CREDS:/hackage-creds:ro -v $DOT_STACKAGE_DIR:/home/stackage/.stackage -v $SSH_DIR:/home/ubuntu/.ssh:ro -v $GITCONFIG:/home/stackage/.gitconfig:ro -v $CABAL_DIR:/home/stackage/.cabal:ro -v $STACK_DIR:/home/stackage/.stack:ro"
# Use cabal update first to initialize ~/.cabal.config, then use stackage-curator update to get it securely
# Make sure we actually need this snapshot
docker run $ARGS_UPLOAD $IMAGE /bin/bash -c "stackage-curator check-target-available --target $TARGET"
docker run $ARGS_PREBUILD $IMAGE /bin/bash -c "cabal update && stackage-curator update && stackage-curator create-plan --plan-file $PLAN_FILE --target $TARGET ${CONSTRAINTS:-} && stackage-curator check --plan-file $PLAN_FILE && stackage-curator fetch --plan-file $PLAN_FILE && cabal install random Cabal cabal-install"
docker run $ARGS_BUILD $IMAGE stackage-curator make-bundle --plan-file $PLAN_FILE --docmap-file $DOCMAP_FILE --bundle-file $BUNDLE_FILE --target $TARGET
# Get latest stack
curl -L https://www.stackage.org/stack/linux-x86_64 | tar xz --wildcards --strip-components=1 -C $EXTRA_BIN_DIR '*/stack'
# Do all of the pre-build actions:
#
# * Update the package index
# * Create a new plan
# * Check that the plan is valid
# * Fetch all needed tarballs (the build step does not have write access to the tarball directory)
# * Do a single unpack to create the package index cache (again due to directory perms)
docker run $ARGS_PREBUILD $IMAGE /bin/bash -c "/home/stackage/bin/stack update && stackage-curator create-plan --plan-file $PLAN_FILE --target $TARGET ${CONSTRAINTS:-} && stackage-curator check --plan-file $PLAN_FILE && stackage-curator fetch --plan-file $PLAN_FILE && cd /tmp && /home/stackage/bin/stack unpack random"
# 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/stackage && sudo -E -u $USER env \"PATH=\$PATH:/home/stackage/bin\" stackage-curator make-bundle --plan-file $PLAN_FILE --docmap-file $DOCMAP_FILE --bundle-file $BUNDLE_FILE --target $TARGET"
# Successful build, so we need to:
#
# * Upload the docs to S3
# * Upload the 00-index.tar file to S3 (TODO: this is probably no longer necessary, since snapshots never modify .cabal files)
# * Upload the new plan .yaml file to the appropriate Github repo
# * Register as a new Hackage distro
docker run $ARGS_UPLOAD $IMAGE /bin/bash -c "stackage-curator upload-docs --target $TARGET --bundle-file $BUNDLE_FILE && stackage-curator upload-index --plan-file $PLAN_FILE --target $TARGET && stackage-curator upload-github --plan-file $PLAN_FILE --docmap-file $DOCMAP_FILE --target $TARGET && stackage-curator hackage-distro --plan-file $PLAN_FILE --target $TARGET"

774
build-constraints.yaml
View File

File diff suppressed because it is too large Load Diff

5
check Executable file
View File

@ -0,0 +1,5 @@
#!/bin/sh
# Convenience script for checking constraints locally
exec stack exec --resolver ghc-7.10.3 stackage-curator check

39
debian-bootstrap.sh
View File

@ -1,4 +1,4 @@
#!/bin/bash -ex
#!/usr/bin/env bash
# Work in progress: create a list of commands necessary to get Stackage
# up-and-running on a freshly installed Debian-based system (including Ubuntu).
@ -10,13 +10,32 @@
# instructions, see:
# http://www.stackage.org/install
set -exu
mkdir /home/stackage -p
locale-gen en_US.UTF-8
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get install -y software-properties-common python-software-properties git
add-apt-repository ppa:hvr/ghc -y
add-apt-repository -y ppa:zoogie/sdl2-snapshots
add-apt-repository -y ppa:marutter/rrutter
add-apt-repository -y ppa:openstack-ubuntu-testing/icehouse
# Get Stack
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 575159689BEFB442
echo 'deb http://download.fpcomplete.com/ubuntu trusty main'|sudo tee /etc/apt/sources.list.d/fpco.list
apt-get update
apt-get install -y \
build-essential \
ghc-7.10.3 \
ghc-7.10.3-htmldocs \
hscolour \
sudo \
curl \
freeglut3-dev \
git \
libadns1-dev \
@ -44,6 +63,8 @@ apt-get install -y \
libleveldb-dev \
liblzma-dev \
libmagic-dev \
libmagickcore-dev \
libmagickwand-dev \
libmysqlclient-dev \
libncurses-dev \
libnotify-dev \
@ -65,6 +86,7 @@ apt-get install -y \
libxml2-dev \
libxss-dev \
libyaml-dev \
libzip-dev \
libzmq3-dev \
llvm \
m4 \
@ -75,19 +97,26 @@ apt-get install -y \
texlive-full \
wget \
zip \
stack \
zlib1g-dev
mkdir /tmp/nettle-build
(
cd /tmp/nettle-build
wget https://ftp.gnu.org/gnu/nettle/nettle-2.7.1.tar.gz
tar zxf nettle-2.7.1.tar.gz
cd nettle-2.7.1
wget https://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gz
tar zxf nettle-3.1.1.tar.gz
cd nettle-3.1.1
./configure --prefix=/usr
make
make install
mkdir -p /usr/lib/x86_64-linux-gnu/
ln -sfv /usr/lib/libnettle.so.4.7 /usr/lib/x86_64-linux-gnu/libnettle.so.4
ln -sfv /usr/lib/libnettle.so.6.1 /usr/lib/x86_64-linux-gnu/libnettle.so.6
)
rm -rf /tmp/nettle-build
# Buggy versions of ld.bfd fail to link some Haskell packages:
# https://sourceware.org/bugzilla/show_bug.cgi?id=17689. Gold is
# faster anyways and uses less RAM.
update-alternatives --install "/usr/bin/ld" "ld" "/usr/bin/ld.gold" 20
update-alternatives --install "/usr/bin/ld" "ld" "/usr/bin/ld.bfd" 10