mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-11 23:08:30 +01:00
Gregory Schwartz
GitHub
commit
adb64d2c0d
21
CURATORS.md
21
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).
|
||||
|
||||
@ -267,8 +275,9 @@ develop this advice over time. For now: if you're not sure, ask for guidance.
|
||||
__`NOPLAN=1`__ If you wish to rerun a build without recalculating a
|
||||
build plan, you can set the environment variable `NOPLAN=1`. This is
|
||||
useful for such cases as an intermittent test failure, out of memory
|
||||
condition, or manually tweaking the plan file. This is the default for
|
||||
LTS builds.
|
||||
condition, or manually tweaking the plan file.
|
||||
|
||||
Note LTS builds inherit the current Hackage data (stack updated for Nigthly) to avoid excess extra rebuilding.
|
||||
|
||||
### Timing
|
||||
|
||||
|
||||
@ -6,6 +6,8 @@ The idea behind Stackage is that, if all packages work with the newest versions
|
||||
* All packages are compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).
|
||||
* All packages in a snapshot are compatible with the versions of libraries that ship with the GHC used in the snapshot ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
|
||||
|
||||
Packages in Stackage are not patched: all package changes occur upstream in Hackage.
|
||||
|
||||
## Adding a package
|
||||
|
||||
Anyone can add any package to Stackage but you may only add packages under your own name. 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.
|
||||
@ -19,6 +21,8 @@ To add a set of packages, you would add:
|
||||
- package2
|
||||
- package3
|
||||
|
||||
Note that the `master` branch is used for Stackage Nightly (not the `nightly` branch, which is used for the nightly docker builder imagine).
|
||||
|
||||
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
|
||||
|
||||
If you want to make sure that the package builds against the newest versions of all dependecies you can do this:
|
||||
@ -44,29 +48,43 @@ recommend waiting an hour before opening the PR. You can verify this
|
||||
by making sure the latest version is listed at
|
||||
https://github.com/commercialhaskell/all-cabal-metadata/tree/master/packages/.
|
||||
|
||||
## Uploading a new package
|
||||
## Uploading a new package version
|
||||
|
||||
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.
|
||||
When a new version of a package in Stackage 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 open a GitHub issue ticket 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 the new version doesn't compile then the package author should 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 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 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 a package is not modified in a timely manner, it may be temporarily
|
||||
removed from Stackage by the curator team, at which point it is your
|
||||
responsibility to add it back in via a new pull request. We typically
|
||||
use fairly long windows on this, but at a minimum:
|
||||
|
||||
**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.
|
||||
* If restrictive version bounds are the only problem, we will give at
|
||||
least a week to respond.
|
||||
* If there are real breaking changes, the curator team will retain
|
||||
more discretion on how long a window to give before dropping
|
||||
packages. Historically, this has usually waited until the cutting of
|
||||
a new Long Term Support (LTS) major version.
|
||||
|
||||
**NOTE** Previously, this maintainer agreement put a time limit on
|
||||
maintainers, requiring a certain level of responsiveness for
|
||||
modifications to be made. We have explicitly removed that: anyone is
|
||||
free to add a package to Stackage regardless of responsiveness
|
||||
guarantees. However, as stated above, we may elect to temporarily
|
||||
remove a package if it is not updated in a timely manner.
|
||||
|
||||
## 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.
|
||||
The soft time limits are intended to prevent 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 longer periods.
|
||||
|
||||
## Upgrading to a new GHC version
|
||||
|
||||
|
||||
@ -123,3 +123,7 @@ 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.
|
||||
|
||||
__What time are Stackage snapshots published?__
|
||||
|
||||
Stackage Nightly and LTS are not released at a fixed time of day, they get pushed to stackage.org (and the metadata to the stackage-nightly and stackage-lts github repos) when their builds finish on the Stackage build server and the latest built haddocks have been synced over. This time varies greatly depending on build times for package updates, bounds breakage, problems with new packages being added and other build issues, etc. There are days when a release does not happen. LTS releases tend to happen over the weekend or early in the week.
|
||||
|
||||
@ -138,4 +138,5 @@ docker run $ARGS_UPLOAD $IMAGE /bin/bash -c "exec stackage-curator check-target-
|
||||
# * 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 && exec stackage-curator hackage-distro --plan-file $PLAN_FILE --target $TARGET"
|
||||
|
||||
echo -n "Completed at "
|
||||
date
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -13,7 +13,6 @@
|
||||
set -exu
|
||||
|
||||
mkdir /home/stackage -p
|
||||
locale-gen en_US.UTF-8
|
||||
|
||||
export DEBIAN_FRONTEND=noninteractive
|
||||
apt-get update
|
||||
@ -21,16 +20,9 @@ apt-get install -y software-properties-common
|
||||
|
||||
add-apt-repository ppa:hvr/ghc -y
|
||||
add-apt-repository -y ppa:marutter/rrutter
|
||||
# not sure what this was needed for
|
||||
#add-apt-repository -y ppa:openstack-ubuntu-testing/icehouse
|
||||
|
||||
# Set the GHC version
|
||||
GHCVER=8.0.2
|
||||
|
||||
# Get Stack
|
||||
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 575159689BEFB442
|
||||
echo 'deb http://download.fpcomplete.com/ubuntu xenial main'|tee /etc/apt/sources.list.d/fpco.list
|
||||
|
||||
apt-get update
|
||||
apt-get install -y \
|
||||
build-essential \
|
||||
@ -43,6 +35,7 @@ apt-get install -y \
|
||||
curl \
|
||||
freeglut3-dev \
|
||||
git \
|
||||
gradle \
|
||||
libadns1-dev \
|
||||
libaio1 \
|
||||
libalut-dev \
|
||||
@ -82,6 +75,7 @@ apt-get install -y \
|
||||
libmagickcore-dev \
|
||||
libmagickwand-dev \
|
||||
libmarkdown2-dev \
|
||||
libmp3lame-dev \
|
||||
libmpfr-dev \
|
||||
libmysqlclient-dev \
|
||||
libncurses-dev \
|
||||
@ -92,8 +86,13 @@ 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 \
|
||||
libsox-dev \
|
||||
libsqlite3-dev \
|
||||
libssl-dev \
|
||||
libsystemd-dev \
|
||||
@ -110,21 +109,30 @@ apt-get install -y \
|
||||
libzip-dev \
|
||||
libzmq3-dev \
|
||||
llvm-3.7 \
|
||||
locales \
|
||||
m4 \
|
||||
nettle-dev \
|
||||
nodejs \
|
||||
npm \
|
||||
openjdk-8-jdk \
|
||||
protobuf-compiler \
|
||||
python-mpltoolkits.basemap \
|
||||
python3-matplotlib \
|
||||
python3-numpy \
|
||||
python3-pip \
|
||||
r-base \
|
||||
r-base-dev \
|
||||
ruby-dev \
|
||||
stack \
|
||||
wget \
|
||||
xclip \
|
||||
z3 \
|
||||
zip \
|
||||
zlib1g-dev
|
||||
|
||||
locale-gen en_US.UTF-8
|
||||
|
||||
curl -sSL https://get.haskellstack.org/ | sh
|
||||
|
||||
# Put documentation where we expect it
|
||||
mv /opt/ghc/$GHCVER/share/doc/ghc-$GHCVER/ /opt/ghc/$GHCVER/share/doc/ghc
|
||||
|
||||
@ -150,9 +158,9 @@ cd /tmp \
|
||||
&& wget https://storage.googleapis.com/oracle.fpinsight.com/instantClient/oracle-instantclient12.1-devel_12.1.0.2.0-2_amd64.deb \
|
||||
&& dpkg -i oracle-instantclient12.1-devel_12.1.0.2.0-2_amd64.deb \
|
||||
&& rm -f oracle-instantclient12.1-devel_12.1.0.2.0-2_amd64.deb \
|
||||
&& wget https://github.com/vrogier/ocilib/archive/v4.2.1.tar.gz \
|
||||
&& tar xvf v4.2.1.tar.gz \
|
||||
&& cd /tmp/ocilib-4.2.1 \
|
||||
&& wget https://github.com/vrogier/ocilib/archive/v4.3.2.tar.gz \
|
||||
&& tar xvf v4.3.2.tar.gz \
|
||||
&& cd /tmp/ocilib-4.3.2 \
|
||||
&& ./configure --with-oracle-import=linkage \
|
||||
--with-oracle-charset=ansi \
|
||||
--with-oracle-headers-path=/usr/include/oracle/12.1/client64 \
|
||||
@ -160,7 +168,7 @@ cd /tmp \
|
||||
&& make \
|
||||
&& make install \
|
||||
&& cd \
|
||||
&& rm -rf /tmp/ocilib-4.2.1 \
|
||||
&& rm -rf /tmp/ocilib-4.3.2 \
|
||||
&& echo "/usr/local/lib" > /etc/ld.so.conf.d/usr-local.conf \
|
||||
&& echo "/usr/lib/oracle/12.1/client64/lib" > /etc/ld.so.conf.d/oracle-client.conf \
|
||||
&& ldconfig
|
||||
@ -168,3 +176,14 @@ cd /tmp \
|
||||
# Add JDK to system paths.
|
||||
echo "/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/" > /etc/ld.so.conf.d/openjdk.conf \
|
||||
&& ldconfig
|
||||
|
||||
# llvm-4.0 for llvm-hs (separate since it needs wget)
|
||||
wget -O - http://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - \
|
||||
&& add-apt-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-4.0 main" \
|
||||
&& apt-get update \
|
||||
&& apt-get install -y llvm-4.0
|
||||
|
||||
## non-free repo for mediabus-fdk-aac
|
||||
#apt-add-repository multiverse \
|
||||
# && apt-get update \
|
||||
# && apt-get install -y libfdk-aac-dev
|
||||
|
||||
Loading…
Reference in New Issue
Block a user