mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-12 23:38:29 +01:00
Michal Konecny
GitHub
commit
6dd2c0e95d
@ -11,7 +11,7 @@ addons:
|
||||
- libgmp-dev
|
||||
|
||||
env:
|
||||
- GHCVER=8.2.1
|
||||
- GHCVER=8.2.2
|
||||
|
||||
install:
|
||||
# Download and unpack the stack executable
|
||||
|
||||
@ -204,6 +204,9 @@ 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.
|
||||
|
||||
You'll need to update both the `PATH` in `Dockerfile` and the `GHCVER` variable
|
||||
in `debian-bootstrap.sh`.
|
||||
|
||||
### 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
|
||||
below). Instead of pulling an unbounded number of images, I typically just
|
||||
|
||||
@ -2,7 +2,11 @@ FROM fpco/pid1:16.04
|
||||
|
||||
ENV HOME /home/stackage
|
||||
ENV LANG en_US.UTF-8
|
||||
ENV PATH /opt/ghc/8.2.1/bin:/usr/sbin:/usr/bin:/sbin:/bin
|
||||
|
||||
# NOTE: also update debian-bootstrap.sh when cuda version changes
|
||||
ENV PATH /usr/local/cuda-8.0/bin:/opt/ghc/8.2.2/bin:/usr/sbin:/usr/bin:/sbin:/bin
|
||||
ENV CUDA_PATH /usr/local/cuda-8.0
|
||||
ENV LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64:/usr/local/cuda-8.0/nvvm/lib64
|
||||
|
||||
ADD debian-bootstrap.sh /tmp/debian-bootstrap.sh
|
||||
RUN /tmp/debian-bootstrap.sh && rm /tmp/debian-bootstrap.sh
|
||||
|
||||
154
MAINTAINERS.md
154
MAINTAINERS.md
@ -12,29 +12,55 @@ Packages in Stackage are not patched: all package changes occur upstream in Hack
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
To add your package you can edit [`build-constraints.yaml`](https://github.com/fpco/stackage/blob/master/build-constraints.yaml) directly on github or fork the project. There's a section called `packages` where you would add yourself and your packages:
|
||||
|
||||
"My Name <myemail@example.com> @mygithubuser":
|
||||
- package1
|
||||
- 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).
|
||||
If your library depends on a C library, please add it to the `debian-bootstrap.sh` script.
|
||||
|
||||
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
|
||||
After doing that commit with a message like "add foo-bar" and send a pull request.
|
||||
|
||||
The continuous integration job will do some checks to see if your package's dependencies are up-to-date.
|
||||
|
||||
The CI job notably doesn't compile packages, run tests, build documentation, or find missing C libraries.
|
||||
If you want to be proactive or if CI fails, you can make sure that your package builds against the latest nightly:
|
||||
|
||||
If you want to make sure that the package builds against the newest versions of all dependecies you can do this:
|
||||
```
|
||||
# Build from the tarball on Hackage to check for missing files
|
||||
$ stack unpack yourpackage && cd yourpackage-*
|
||||
# Generate a pristine stack.yaml, adding any missing extra-deps
|
||||
$ rm -f stack.yaml && stack init --resolver nightly --solver
|
||||
# Build, generate docs, test, and build benchmarks
|
||||
$ stack build --resolver nightly --haddock --test --bench --no-run-benchmarks
|
||||
```
|
||||
|
||||
This approach works well, but has two limitations you should be aware
|
||||
of:
|
||||
|
||||
* It won't notify you of restrictive upper bounds in your package if
|
||||
Stackage has the same upper bounds. For that reason, we recommend
|
||||
using [Packdeps](http://packdeps.haskellers.com/) (see "Following
|
||||
dependency upgrades" below).
|
||||
* If the latest Stackage Nightly is missing some of the latest
|
||||
packages, your build above may succeed whereas the Travis job may
|
||||
fail. Again: Packdeps will help you detect this situation.
|
||||
|
||||
Alternatively, you can build with `cabal`. Note that this may end up
|
||||
using older dependency versions:
|
||||
|
||||
```
|
||||
$ ghc --version # Should be the same as the latest nightly, it's in the title of https://www.stackage.org/nightly
|
||||
$ cabal update
|
||||
$ ghc --version # Should give v8.0.2
|
||||
$ cabal get PACKAGE-VERSION # e.g. aeson-0.11.2.1
|
||||
$ cd PACKAGE-VERSION
|
||||
$ cabal get PACKAGE
|
||||
$ cd PACKAGE-*
|
||||
$ cabal sandbox init # Should give "Creating a new sandbox" and not "Using an existing sandbox".
|
||||
$ cabal install --enable-tests --enable-benchmarks --dry-run | grep latest # Should give no results
|
||||
$ cabal install --enable-tests --enable-benchmarks --allow-newer
|
||||
$ cabal test
|
||||
$ cabal haddock
|
||||
```
|
||||
|
||||
**NB** Please use commit messages like "add foo-bar" or "add johndev's packages"
|
||||
@ -45,56 +71,103 @@ so commit messages like "update build-constraints.yaml" are not helpful).
|
||||
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. You can verify this
|
||||
by making sure the latest version is listed at
|
||||
by making sure the latest version is listed at
|
||||
https://github.com/commercialhaskell/all-cabal-metadata/tree/master/packages/.
|
||||
|
||||
## Github and Notifications
|
||||
|
||||
Stackage uses Github notifications to reduce overhead of contacting individual
|
||||
package maintainers through various channels. As a package maintainer, you will
|
||||
receive notifications for a number of reasons, package build failures of
|
||||
different sorts, blockages and bounds issues, etc.
|
||||
|
||||
Please note, Github does some throttling on the number people that can be
|
||||
notified within one issue. This means that on issues created with a large
|
||||
number of packages affected, maintainers may not receive a notification. This
|
||||
is not ideal, but Stackage is largely a manual process and done on a best
|
||||
effort basis.
|
||||
|
||||
## Uploading a new package version
|
||||
|
||||
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.
|
||||
When a new version of a package in Stackage is uploaded to Hackage, we automatically try to include it in Stackage. 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 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 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 your package may fail to
|
||||
build or tests may fail. In most cases we will add an upper bound on
|
||||
the dependency so that your package remains in nightly. We'll also
|
||||
create a github issue pinging you with the bounds issues or give build
|
||||
logs showing failures. It's then up to you to modify your package.
|
||||
|
||||
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:
|
||||
We recommend that you also follow the dependencies of your packages on
|
||||
[Packdeps](http://packdeps.haskellers.com/) (typically using the RSS
|
||||
feeds) as well as that often gives you notice ahead of stackage
|
||||
issues. There are cases where we will not notice a new release of a
|
||||
package because of other upper bounds that are in place.
|
||||
|
||||
* If restrictive version bounds are the only problem, we will give at
|
||||
least a week to respond.
|
||||
If a package is not updated in time, it may be temporarily removed
|
||||
from Stackage by the curator team. We strive to notify you when this
|
||||
happens. If it does you are always welcome to file another pull
|
||||
request to add it back.
|
||||
|
||||
We typically use fairly long windows before disabling packages, but it
|
||||
is decided on a case-by-case basis.
|
||||
|
||||
* If restrictive version bounds are the only problem, we will give
|
||||
maintainers 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
|
||||
packages.
|
||||
* We usually drop all upper bounds and disable packages when we create
|
||||
a new Long Term Support (LTS) major version.
|
||||
* There are rare cases where an upper bound or build failure are hard
|
||||
to deal with so then we may disable
|
||||
|
||||
**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.
|
||||
**NOTE** Previously we had stricter time limits, but we decided to
|
||||
remove 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
|
||||
## Delays
|
||||
|
||||
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.
|
||||
Maintainers are humans, humans get sick/have babies/go on
|
||||
holiday. Sometimes a dependency upgrade is extra time consuming.
|
||||
|
||||
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.
|
||||
Consider finding a co-maintainer with access to SCM and Hackage to
|
||||
help you out.
|
||||
|
||||
We appreciate if you notify us of any expected delays in the Github
|
||||
issues, some kind soul might decide to help out.
|
||||
|
||||
## Upgrading to a new GHC version
|
||||
|
||||
The Stackage curation team tries to move Stackage Nightly to new versions of GHC quickly as they become available, while keeping LTS Haskell on a regular release schedule. For package maintainers, the most important impacts of a new GHC release are:
|
||||
The Stackage curation team tries to move Stackage Nightly to new
|
||||
versions of GHC quickly as they become available, while keeping LTS
|
||||
Haskell on a regular release schedule. For package maintainers, the
|
||||
most important impacts of a new GHC release are:
|
||||
|
||||
* We will typically do a sweep through the Stackage upper bounds and aggressively remove packages that block them. This is because, in most cases, we will need to move to the newest versions of a package to get support for the latest GHC, and asking package maintainers to backport their fixes is an undue burden
|
||||
* We will definitely do this at a GHC major version release, and may do so at a minor version release
|
||||
* Packages that are incompatible with the newest GHC version will be temporarily blocked
|
||||
* We will typically do a sweep through the Stackage upper bounds and
|
||||
remove blocking packages. We prefer to do it this way rather than
|
||||
ask other maintainers to backport fixes.
|
||||
* We will definitely do this at a GHC major version release, and
|
||||
may do so at a minor version release
|
||||
* Packages that are incompatible with the newest GHC version will be
|
||||
temporarily disabled
|
||||
|
||||
If your package ends up being temporarily removed from Stackage Nightly, please simply send a pull request to add it back once it and its dependencies are compatible with the newest GHC version.
|
||||
If your package ends up being temporarily disabled from Stackage
|
||||
Nightly, please simply send a pull request to add it back once it and
|
||||
its dependencies are compatible with the newest GHC version.
|
||||
|
||||
Note that it is _not_ a goal of LTS Haskell to track the latest
|
||||
version of GHC. If you want the latest and greatest, Stackage Nightly
|
||||
is your best bet. In particular, LTS Haskell will often—but not
|
||||
always—avoid upgrading to the first point release of GHC
|
||||
releases (e.g., 8.2.1) to allow further testing and to get the
|
||||
benefits of the first bugfix release (e.g., 8.2.2).
|
||||
|
||||
## Adding a package to an LTS snapshot
|
||||
|
||||
@ -108,8 +181,13 @@ If you would like to get your package added to an existing LTS Haskell major
|
||||
release (e.g., if `lts-8.9` is out, you would want your package to appear in
|
||||
`lts-8.10`), please do the following in addition to the steps above:
|
||||
|
||||
* Check that your package can be built with that LTS major version (e.g. `stack build --test --bench --haddock --resolver lts-8.10`)
|
||||
* 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-8)
|
||||
* Provide a list of packages you would like added, and if relevant, any upper bounds on those packages
|
||||
* Be patient! The LTS releases are less frequent than Nightly and by their nature more conservative, and therefore adding new packages is a more manual process. The Stackage curators will try to get to your issue as soon as possible, but it may take some time.
|
||||
* To add a package to more than one LTS version please file separate tickets for each major LTS release, since they will typically be built and added at different times.
|
||||
* Specify the LTS major versions you would like your packages to go into (e.g. lts-8)
|
||||
* Provide a list of packages you would like added
|
||||
* If relevant, mention any upper bounds that are needed on those packages
|
||||
* Be patient! The LTS releases are less frequent than Nightly. The
|
||||
Stackage curators will try to get to your issue as soon as possible,
|
||||
but it may take some time.
|
||||
* We gradually stop maintainng old LTS major versions, so your
|
||||
request may take longer or be declined if it's for an old LTS.
|
||||
|
||||
@ -37,7 +37,6 @@ project information. In addition, we have the following repositories:
|
||||
|
||||
* [stackage-server](https://github.com/fpco/stackage-server) [](https://travis-ci.org/fpco/stackage-server)
|
||||
* [stackage-curator](https://github.com/fpco/stackage-curator) [](https://travis-ci.org/fpco/stackage-curator)
|
||||
* [stackage-types](https://github.com/fpco/stackage-types) [](https://travis-ci.org/fpco/stackage-types)
|
||||
* [lts-haskell](https://github.com/fpco/lts-haskell)
|
||||
* [stackage-nightly](https://github.com/fpco/stackage-nightly)
|
||||
|
||||
@ -58,7 +57,7 @@ Build the package set
|
||||
---------------------
|
||||
|
||||
Generally only the stackage build server run by the stackage curator
|
||||
team and people intrested in incorporating stackage snapshots into an
|
||||
team and people interested in incorporating stackage snapshots into an
|
||||
OS distribution need to build the entire package set. If you're
|
||||
interested in trying this yourself, please check out
|
||||
[the curator guide](https://github.com/fpco/stackage/blob/master/CURATORS.md),
|
||||
|
||||
@ -30,6 +30,7 @@ DOT_STACKAGE_DIR=$ROOT/dot-stackage
|
||||
WORKDIR=$ROOT/$TAG/work
|
||||
EXTRA_BIN_DIR=$ROOT/extra-bin
|
||||
SSH_DIR=$ROOT/ssh-$SHORTNAME
|
||||
USERID=$(id -u)
|
||||
|
||||
mkdir -p \
|
||||
"$CABAL_DIR" \
|
||||
@ -81,9 +82,9 @@ chmod +x stackage-curator
|
||||
)
|
||||
|
||||
ARGS_COMMON="--rm -v $WORKDIR:$HOME/work -w $HOME/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/stack:/usr/bin/stack:ro"
|
||||
ARGS_PREBUILD="$ARGS_COMMON -u $USER -e HOME=$HOME -v $CABAL_DIR:$HOME/.cabal -v $STACK_DIR:$HOME/.stack -v $GHC_DIR:$HOME/.ghc -v $DOT_STACKAGE_DIR:$HOME/.stackage"
|
||||
ARGS_PREBUILD="$ARGS_COMMON -u $USERID -e HOME=$HOME -v $CABAL_DIR:$HOME/.cabal -v $STACK_DIR:$HOME/.stack -v $GHC_DIR:$HOME/.ghc -v $DOT_STACKAGE_DIR:$HOME/.stackage"
|
||||
ARGS_BUILD="$ARGS_COMMON -v $CABAL_DIR:$HOME/.cabal:ro -v $STACK_DIR:$HOME/.stack:ro -v $GHC_DIR:$HOME/.ghc:ro"
|
||||
ARGS_UPLOAD="$ARGS_COMMON -u $USER -e HOME=$HOME -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY -v $AUTH_TOKEN:/auth-token:ro -v $HACKAGE_CREDS:/hackage-creds:ro -v $DOT_STACKAGE_DIR:$HOME/.stackage -v $SSH_DIR:$HOME/.ssh:ro -v $GITCONFIG:$HOME/.gitconfig:ro -v $CABAL_DIR:$HOME/.cabal:ro -v $STACK_DIR:$HOME/.stack:ro"
|
||||
ARGS_UPLOAD="$ARGS_COMMON -u $USERID -e HOME=$HOME -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY -v $AUTH_TOKEN:/auth-token:ro -v $HACKAGE_CREDS:/hackage-creds:ro -v $DOT_STACKAGE_DIR:$HOME/.stackage -v $SSH_DIR:$HOME/.ssh:ro -v $GITCONFIG:$HOME/.gitconfig:ro -v $CABAL_DIR:$HOME/.cabal:ro -v $STACK_DIR:$HOME/.stack:ro"
|
||||
|
||||
# Make sure we actually need this snapshot. We only check this for LTS releases
|
||||
# since, for nightlies, we'd like to run builds even if they are unnecessary to
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
2
check
2
check
@ -3,4 +3,4 @@
|
||||
# Convenience script for checking constraints locally
|
||||
|
||||
cd `dirname $0`
|
||||
exec stack exec --resolver ghc-8.2.1 stackage-curator check
|
||||
exec stack exec --resolver ghc-8.2.2 stackage-curator check
|
||||
|
||||
@ -25,14 +25,17 @@ add-apt-repository -y --keyserver hkp://keyserver.ubuntu.com:80 'deb http://down
|
||||
add-apt-repository -y --keyserver hkp://keyserver.ubuntu.com:80 'deb http://download.mono-project.com/repo/debian wheezy-apache24-compat main'
|
||||
add-apt-repository -y --keyserver hkp://keyserver.ubuntu.com:80 'deb http://download.mono-project.com/repo/debian wheezy-libjpeg62-compat main'
|
||||
|
||||
GHCVER=8.2.1
|
||||
GHCVER=8.2.2
|
||||
|
||||
apt-get update
|
||||
apt-get install -y \
|
||||
build-essential \
|
||||
cmake \
|
||||
curl \
|
||||
freeglut3-dev \
|
||||
fsharp \
|
||||
g++ \
|
||||
gawk \
|
||||
ghc-$GHCVER \
|
||||
ghc-$GHCVER-dyn \
|
||||
ghc-$GHCVER-htmldocs \
|
||||
@ -89,6 +92,7 @@ apt-get install -y \
|
||||
libmysqlclient-dev \
|
||||
libncurses-dev \
|
||||
libnfc-dev \
|
||||
liboath-dev \
|
||||
libnotify-dev \
|
||||
libopenal-dev \
|
||||
libpango1.0-dev \
|
||||
@ -124,6 +128,7 @@ apt-get install -y \
|
||||
minisat \
|
||||
mono-mcs \
|
||||
nettle-dev \
|
||||
ninja-build \
|
||||
nodejs \
|
||||
npm \
|
||||
openjdk-8-jdk \
|
||||
@ -191,9 +196,9 @@ echo "/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/" > /etc/ld.so.conf
|
||||
|
||||
# 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" \
|
||||
&& add-apt-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-5.0 main" \
|
||||
&& apt-get update \
|
||||
&& apt-get install -y llvm-4.0
|
||||
&& apt-get install -y llvm-5.0
|
||||
|
||||
# Install version 3 of the protobuf compiler. (The `protobuf-compiler` package only
|
||||
# supports version 2.)
|
||||
@ -207,7 +212,26 @@ curl https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-cpu-l
|
||||
&& rm libtensorflow.tar.gz \
|
||||
&& ldconfig
|
||||
|
||||
## non-free repo for mediabus-fdk-aac
|
||||
#apt-add-repository multiverse \
|
||||
# && apt-get update \
|
||||
# && apt-get install -y libfdk-aac-dev
|
||||
# NOTE: also update Dockerfile when cuda version changes
|
||||
# Install CUDA toolkit
|
||||
# The current version can be found at: https://developer.nvidia.com/cuda-downloads
|
||||
CUDA_PKG=8.0.61-1 # update this on new version
|
||||
CUDA_VER=${CUDA_PKG:0:3}
|
||||
CUDA_APT=${CUDA_VER/./-}
|
||||
|
||||
pushd /tmp \
|
||||
&& wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_${CUDA_PKG}_amd64.deb \
|
||||
&& dpkg -i cuda-repo-ubuntu1604_${CUDA_PKG}_amd64.deb \
|
||||
&& apt-get update -qq \
|
||||
&& apt-get install -y cuda-drivers cuda-core-${CUDA_APT} cuda-cudart-dev-${CUDA_APT} cuda-cufft-dev-${CUDA_APT} cuda-cublas-dev-${CUDA_APT} cuda-cusparse-dev-${CUDA_APT} cuda-cusolver-dev-${CUDA_APT} \
|
||||
&& rm cuda-repo-ubuntu1604_${CUDA_PKG}_amd64.deb \
|
||||
&& export CUDA_PATH=/usr/local/cuda-${CUDA_VER} \
|
||||
&& export LD_LIBRARY_PATH=${CUDA_PATH}/nvvm/lib64:${LD_LIBRARY_PATH+x} \
|
||||
&& export LD_LIBRARY_PATH=${CUDA_PATH}/lib64:${LD_LIBRARY_PATH} \
|
||||
&& export PATH=${CUDA_PATH}/bin:${PATH} \
|
||||
&& popd
|
||||
|
||||
# non-free repo for mediabus-fdk-aac
|
||||
apt-add-repository multiverse \
|
||||
&& apt-get update \
|
||||
&& apt-get install -y nvidia-cuda-dev
|
||||
|
||||
Loading…
Reference in New Issue
Block a user