opm - User contributions [en]

Debian Packaging Workflow

2022-03-30T19:42:00Z

Markusblatt: /* Building the package */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>. This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a pre-release version using an upstream git commit or tag ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that the branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead. Note. that the version includes the date of the commit to make the order of the releases sensible.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"
and create that directory if it is not present

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
#BUILDRESULT=$DEPSbase/$DEPS
else
#BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

=== Finishing touches and uploading of the release ===

* Update debian/changelog: <code>gbp dch</code>
* Polish debian/changelog.
* push changes, e.g. by <code>gbp push</code>
* Ask Markus (he is a Debian Maintainer) to upload the release

The uploader should:
* Test the package build
* Release debian/changelog: <code>dch -r</code>
* Tag the release: <code>gbp tag --sign-tags</code>
* Push the changes: <code>gbp push</code>

Debian Packaging Workflow

2022-03-30T19:32:20Z

Markusblatt: /* Performing builds using locally built packages */

Debian Packaging Workflow

2022-03-30T19:31:53Z

Markusblatt: /* Additional setup instructions */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>. This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a pre-release version using an upstream git commit or tag ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that the branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead. Note. that the version includes the date of the commit to make the order of the releases sensible.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"
and create that directory if it is not present

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T19:31:38Z

Markusblatt: /* Additional setup instructions */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>. This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a pre-release version using an upstream git commit or tag ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that the branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead. Note. that the version includes the date of the commit to make the order of the releases sensible.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"
and create that dorectory if it is not present

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T19:31:00Z

Markusblatt: /* Import a pre-release version using an upstream git commit or tag */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>. This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a pre-release version using an upstream git commit or tag ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that the branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead. Note. that the version includes the date of the commit to make the order of the releases sensible.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T19:29:31Z

Markusblatt: /* Import a pre-release version using an upstream git commit */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>. This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a pre-release version using an upstream git commit or tag ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T19:29:06Z

Markusblatt: /* Import a prerelease version using an upstream git commit */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>. This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a pre-release version using an upstream git commit ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T19:28:49Z

Markusblatt: /* repository management with git-buildpackage */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>. This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a prerelease version using an upstream git commit ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T19:28:25Z

Markusblatt: /* Repositories on Salsa */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on [https://salsa.debian.org salsa]. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>
This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a prerelease version using an upstream git commit ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T15:31:28Z

Markusblatt: /* Notes on Maintaining the Debian Packages */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on sala. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>
This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): <code>gbp pull</code>
* import new version: <code>gbp import-orig --uscan</code>
* Change changelog: <code>dch --newversion <new-version></code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful
* Do further work on the package.

==== Import a prerelease version using an upstream git commit ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz
dch --newversion $VERSION

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T15:24:51Z

Markusblatt: /* Building the package */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on sala. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>
This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): gbp pull
* import new version: <code>gbp import-orig --uscan</code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful

==== Import a prerelease version using an upstream git commit ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package using pbuilder in the chroot is done using the command:

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T15:24:06Z

Markusblatt: /* Performing builds using locally built packages */

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on sala. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>
This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): gbp pull
* import new version: <code>gbp import-orig --uscan</code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful

==== Import a prerelease version using an upstream git commit ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

=== Building the package ===

Building the package is done easily using the command

DEPS=opm-sid gbp buildpackage --git-ignore-new \
--git-export-dir=../build-area-pbuilder-sid --git-pbuilder

Debian Packaging Workflow

2022-03-30T15:21:04Z

Markusblatt:

== Notes on Maintaining the Debian Packages ==

Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rather outdated. The Debian packaging effort takes place on [https://salsa.debian.org salsa.debian.org] and is managed by the [https://wiki.debian.org/Teams/DebianScience Debian Science Team]. To contribute you will have to create an account on salsa.debian.org and apply for being added to the [https://salsa.debian.org/science-team Debian Science Team]. If it takes long then you might want to send an email to the Debian Science mailinglist [mailto:debian-science@lists.debian.org debian-science@lists.debian.org].

=== Repositories on Salsa ===

For each module there is a corresponding repository on sala. These are:
* [https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-common]
* [https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-material]
* [https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-grid]
* [https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-models]
* [https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-simulators]
* [https://salsa.debian.org/science-team/opm-upscaling https://salsa.debian.org/science-team/opm-upscaling]

The packaging effort uses [https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage] as the main tool and bases the packaging on release tarballs and quilt for patching the upstream versions found in OPM's git repositories.

=== git-buildpackage instruction ===

==== repository management with git-buildpackage ====

* To clone a repository please use gbp use e.g.: <code>gbp clone https://salsa.debian.org/science-team/opm-common</code>
This will clone the repository with the three banches master (Where the debian packaging effort is), upstream (The upstream repository as of the last release that was imported), and pristine-tar (The branch holding the deltas for reconstructing the original tarball).
* To download the recent changes to the packaging effort from other do <code>gbp pull</code>
* To upload your recent changes (to all relevant branches) use <code>gbp push</code>

==== Import new (final) upstream release ====

For more information see [https://https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html gbp documentation].

For importing a new upstream version, please follow the following recipe:
* If not done yet, add the upstream git to repo , e.g. <code>git remote add upstream https://github.com/OPM/opm-common</code>
* make sure the patch-queue branch is up to date
* update upstream: <code>git fetch upstream</code>
* update necessary branches from debian repo (in case of changes from others): gbp pull
* import new version: <code>gbp import-orig --uscan</code>
* rebase patch queue: <code>gbp pq rebase</code>
* resolve conflicts, etc.
* export the patch queue: <code>gbp pq export --commit</code>
* change the commit message to something more meaningful

==== Import a prerelease version using an upstream git commit ====

Instead of importing the new version using uscan as above, you manually create a tarball based on a git checkout of upstream.
This assumes that you have checked out the version that you need (e.g. by <code>git checkout upstream/master</code>).

PACKAGE=opm-common # name of the package
NEXTVERSION=2022.04 # next stable version
VERSION=$(git log -1 --date=format:%Y%m%d --pretty=$NEXTVERSION~git%cd.%h)
TAG=$(git rev-parse --short HEAD)
PREFIX=${PACKAGE}_${VERSION}; DIR_PREFIX=${PACKAGE}-${VERSION};
git archive --format=tar --prefix=$DIR_PREFIX/ HEAD | gzip -c > ../$PREFIX.orig.tar.gz
git checkout master # branch with the debian packaging
gbp import-orig --upstream-vcs-tag=$TAG ../$PREFIX.orig.tar.gz

Doing it this way will make sure that branch upstream contains the complete upstream git history. Note that one could also use a git tag instead of a git commit hash instead.

== Building the packages in a chroot using cowbuilder ==

These instructions are for using [https://wiki.debian.org/cowbuilder cowbuilder] to build the packages in a chroot. Please follow the instructions described in the previous link to set it up.

=== Additional setup instructions ===

To make the following work, please make sure that there is a <code>$HOME/.pbuilderrc</code> with an entry that sets the HOOKDIR like
# the hook dir may already be set/populated!
HOOKDIR="$HOME/.pbuilder/hooks/"

==== Running autopkgtest ====

The packages of the OPM modules come with autopkgtest that will test the installed packages for usability. As it is really handy to have these tests run when building the packages, you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first.

==== Running Lintian ====

Lintian will do a lot of sanity checks for the built packages. To run it automatically you should copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Opening a shell in case of a failed build ====

To investigate problems if a build is failing, it is handy to open a shell in the chroot in case of failure. To do that simply copy the file <code>/usr/share/doc/pbuilder/examples/B20autopkgtest</code> to <code>$HOME/.pbuilder/hooks</code> (you might need to create that directory first).

==== Performing builds using locally built packages ====

As OPM consists of multiple modules that depend on each other, for a new release we need to build all of this modules and test them at once. To do that we copy the built modules to <code>/var/cache/pbuilder/deps/opm-sid/</sid> and let cowbuilder create a local repository for that. To do that create a file <code>$HOME/.pbuilder/hooks/D05deps/</code> with the following content:

DEPSPATH="$DEPSBASE/$DEPS"
if [ -n "$DEPS" ] && [ -d "$DEPSPATH" ] ; then
apt-get install --assume-yes apt-utils
( cd "$DEPSPATH"; apt-ftparchive packages . > Packages )
echo "deb [trusted=yes] file://$DEPSPATH ./" >> /etc/apt/sources.list
apt-get update
fi

Also add the following code to <code>$HOME/.pbuilderrc</code>:

if [ -n "$DEPS" ] ; then
export DEPSBASE=/var/cache/pbuilder/deps
BINDMOUNTS=$DEPSBASE
BUILDRESULT=$DEPSbase/$DEPS
else
BUILDRESULT=/var/cache/pbuilder/result
fi

Debian Packaging Workflow

2022-03-30T13:29:35Z

Markusblatt: /* Import a prerelease version using a tarball of a git commit */

Debian Packaging Workflow

2022-03-30T13:15:54Z

Markusblatt:

Debian Packaging Workflow

2022-03-29T14:09:04Z

Markusblatt: Created page with "== Notes on Maintaining the Debian Packages == Although you may still find a debian subdirectory in our OPM repositories this is obsolete and should not be used as it is rath..."

Main Page

2022-03-29T13:43:32Z

Markusblatt:

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* Black-oil reservoir simulator Flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

=== Notes on Debian Packages ===

[[Debian Packaging Workflow]]

= Viewing ECLIPSE summary files =
[//resinsight.org/ Resinsight] provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. Resinsight can be installed from [//opm-project.org/?page_id=245 packages or source].

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. No binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2022-03-29T13:43:06Z

Markusblatt:

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* Black-oil reservoir simulator Flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

=== Notes on Debian Packages ====

[[Debian Packaging Workflow]]

= Viewing ECLIPSE summary files =
[//resinsight.org/ Resinsight] provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. Resinsight can be installed from [//opm-project.org/?page_id=245 packages or source].

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. No binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Quick Installation

2022-02-07T20:19:26Z

Markusblatt: removed outdated installation instructions and linked to webpage

DOWNLOAD AND INSTALL
-----------

Please read the installation notes on our website: https://opm-project.org/?page_id=36

REPORTING ISSUES
----------------

Issues can be reported in the Git issue tracker online at:

http://github.com/OPM/opm-simulators/issues

To help diagnose build errors, please provide a link to a build log together
with the issue description.

You can capture such a log from the build using the `script' utility, e.g.:

LOGFILE=$(date +%Y%m%d-%H%M-)build.log ;
cmake -E cmake_echo_color --cyan --bold "Log file: $LOGFILE" ;
script -q $LOGFILE -c 'cmake ../opm-core -DCMAKE_BUILD_TYPE=Debug' &&
script -q $LOGFILE -a -c 'ionice nice make -j 4 -l 3' ||
cat CMakeCache.txt CMakeFiles/CMake*.log >> $LOGFILE

The resulting file can be uploaded to for instance gist.github.com.