From 49431b99ba6d3ae295f3e5aa85f65c24a97862de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Otto=20Kek=C3=A4l=C3=A4inen?= Date: Fri, 31 Aug 2018 21:14:25 +0200 Subject: [PATCH] Update README.Maintainer to match current best practices --- debian/README.Maintainer | 166 +++++++++++++++++++++++++-------------- 1 file changed, 108 insertions(+), 58 deletions(-) diff --git a/debian/README.Maintainer b/debian/README.Maintainer index 1750e53c..f8e6306e 100644 --- a/debian/README.Maintainer +++ b/debian/README.Maintainer @@ -1,46 +1,45 @@ -# README for Debian package maintainers # +# README for Debian package maintainers This file mostly applies to how the packaging work-flow works for the official Debian packages, but it may contain useful information also for anybody doing their own private .deb builds. +## Version control -## Building from sources with git-buildpackage ## - -Clone sources with all branches - sudo apt-get install git-buildpackage - gbp-clone --pristine-tar git://git.debian.org/git/pkg-mysql/mariadb-10.1.git - -Alternatively use Github mirror at https://github.com/ottok/mariadb-10.1.git +This package is maintained by the MariaDB/MySQL team in Debian using the +git-buildpackage tool and storing the git repositories on the Debian Gitlab +instance Salsa. For details see https://salsa.debian.org/mariadb-team/. -On later runs make sure to have latest version of sources - gbp-pull --pristine-tar --force +The official Ubuntu packages are also maintained by the same team using the same +source repository. +### Ensuring git contents match what has been uploaded to Debian/Ubuntu -Build - git-buildpackage --git-pristine-tar +It is possible (but extremely rare) that somebody uploads a MariaDB package to +Debian/Ubuntu and either does not use git at all, or simply forgets to push the +same changes on git, or makes an error in tagging the release or something. +Therefore maintainers should check that the git contents match what has been +uploaded to Debian/Ubuntu before making new changes on git. -For a more elaborate setup with automatic build dependency installation and -multi-target chroot usage check out how http://labs.seravo.fi/~otto/mariadb-repo/build.sh -uses git-buildpackage with pbuilder. +This can be done by using dgit. The example command below will fetch the latest +mariadb-10.0 package available in Ubuntu 16.04 (Xenial) base archive or security +archive (whichever has a newer version): + dgit -d ubuntu clone mariadb-10.0 xenial,-security -If the build fails the easiest way to clean up before a new run is - git clean -fdx && git reset --hard +You can then compare these two directories with a recursive diff. +Another option is to manually check on packages.debian.org or packages.ubuntu.com +what is the latest version, and download and extract it on top of the existing +debian/ directory with: + curl -SL http://archive.ubuntu.com/ubuntu/pool/universe/m/mariadb-10.0/\ + mariadb-10.0_10.0.34-0ubuntu0.16.04.1.debian.tar.xz -o - | tar xv --xz -### Tip ### +The you can simply run `git diff` to see the report on differences. - Don't run the mysql-test-run test suite as part of build. - It takes a lot of time, and we will do a better test anyway in - Buildbot, running the test suite from installed .debs on a clean VM. - export DEB_BUILD_OPTIONS="nocheck" - - If you want to run the build in parallel on 2 CPUs and have verbose output, use: - export DEB_BUILD_OPTIONS="parallel=2 verbose" - - The options above can also be combined freely to get required behaviour. +## Building from sources with git-buildpackage ## +See README.Contribute for details. ## Importing initial sources from upstream the first fime ## @@ -49,7 +48,7 @@ Create repository cd mariadb-10.1 git init git branch upstream - git-import-orig --pristine-tar ../../upstream/mariadb-10.1.20 + gbp import-orig --pristine-tar ../../upstream/mariadb-10.1.20 Fill in values prompted What will be the source package name? [mariadb] mariadb-10.1 @@ -81,44 +80,63 @@ https://mariadb.com/kb/en/mariadb/development/release-notes/ Download new source package cd pkg-mariadb-10.1 - uscan --verbose + gbp import-orig --uscan --no-interactive --verbose -Enter git repository path and apply new sources - cd mariadb-10.1 - git-import-orig --pristine-tar ../mariadb-10.1.20.tar.gz +Refresh patches + while quilt push; do quilt refresh; done; quilt pop -a + +Simple offsets will be updated automatically. If there are any rejects, inspect +the files and update the patches or discard the patch completely if you are +_sure_ that it has been applied upstream. Generate new debian/changelog entry automatically with git-dch git-dch -avR -Manually merge what needs to be done +Edit the details to match correct release + gedit debian/changelog & + +Commit to git + git citool + +Build and test locally to verify it works. + gbp buildpackage --git-pristine-tar + +Alternatively you can use Docker with something like this: + mkdir ccache buildout + docker run -it -v "${PWD}/buildout":/tmp/build -v "${PWD}/ccache":/.ccache \ + -v "${PWD}/$PKG":/tmp/build/source -w /tmp/build/source \ + -e DEB_BUILD_OPTIONS="$DEB_BUILD_OPTIONS" -e CCACHE_DIR=/var/cache/ccache \ + --user=1001 registry.gitlab.com/mariadb/mariadb.org-build-containers:$PKG-debian-sid-build-env \ + gbp buildpackage --git-pristine-tar -us -uc | tee latest.build -Commit and push - git commit -am "Merged with upstream 10.1.20" - git push --all; git push --all github - git push --tags; git push --tags github +If needed, add commits or amend the ones you made until the package is in +perfect shape. -Note that in above if you want to sync to Github directly you need to have -collaborator rights to the Github repo and you need to add it as a secondary -remote location with: - git remote add origin git@github.com:ottok/mariadb-10.1.git +Then proceed to make a source only build + gbp buildpackage -S -To push to the git.debian.org repos you need to a member of the pkg-mysql team -at Alioth. It does not matter which repository you push to, eventually they are -synced with each other anyway. +Test more with upload to Launchpad + COMMIT_ID=`git log -n 1 --oneline | cut -d ' ' -f 1` + PKG=mariadb-10.1 + backportpackage --yes -u ppa:mysql-ubuntu/$PKG -d xenial -S ~`date '+%s'`.$COMMIT_ID $PKG*.dsc +When done, push to Salsa: + git push -v -### Maintaining patches ### +Wait until the Salsa CI pipeline finishes. If it did not either spot any +regressions, proceed to tagging the commit: + git tag -s ... + git push --tags -Test that the patches still apply by running: - export QUILT_PATCHES=debian/patches - quilt import - quilt push -a +Sign and upload to autobake for one final round of testing: + dput autobake *.changes -If there are any rejects, inspect the files and update the patches. +Once you are sure there are no regressions, finally upload to Debian + dput ftp-master *.changes -If there are simple offsets we can refresh the patches simply with: - quilt pop -a - while quilt push; do quilt refresh; done +After the upload, check that everything is OK at +* https://tracker.debian.org/mariadb-10.1 (Debian) +* https://launchpad.net/ubuntu/+source/mariadb-10.1 (Ubuntu) ### Maintaining debian/copyright ### @@ -138,10 +156,10 @@ those cleaned up. ### Quality control ### Run wrap-and-sort to style contents in debian/* - wrap-and-sort + wrap-and-sort -a -t -v Once packages are done check their quality with Lintian - lintian -EvIL +pedantic --color=always *.deb + lintian -EvIL +pedantic --color=always *.changes ## Uploading to Ubuntu PPA for testing ## @@ -154,8 +172,23 @@ These are good to have as environment variables (replace values with your own) DEBFULLNAME="Otto Kekäläinen" export DEBEMAIL DEBFULLNAME -The run the commands to automatically change version and upload - backportpackage -u ppa:mysql-ubuntu/mariadb -d precise -r *.dsc -S ~ppa1 -y +Then run the commands to automatically change version and upload + backportpackage --yes -u ppa:mysql-ubuntu/$PKG -d xenial -S ~`date '+%s'`.$COMMIT_ID $PKG*.dsc + +### Launchpad testing matrix + +Since Launchpad only has Ubuntu releases, packages for specific Debian releases +needs to be tested on the Ubuntu release which most closely matches the Debian +release in question. The following matrix maps what package should be tested +where: + +- 10.3 for sid on launchpad cosmic +- 10.1 for bionic on launchpad bionic +- 10.0 for xenial on launchpad xenial +- 10.1 for sid on launchpad cosmic +- 10.1 for stretch on launchpad xenial +- 10.0 for jessie on launhcpad trusty +- 5.5. for trusy on launchpad trusty ## Uploading to Ubuntu security releases ## @@ -170,6 +203,24 @@ that Ubuntu security team can apply upon the mix of previous debian/ contents from Ubuntu archive and updated others from upstream. This would allow to use git-buildpackage to produce test builds instead of plain 'fakeroot dpkg-buildpackage'. +### Upload priority + +Do the security uploads in this order for having the best chance of catching +regressions before they spread out to too many users. + +Upload priority for 10.1 +- debian sid +- debian stretch +- ubuntu bionic + +for 10.0 +- debian jessie +- ubuntu xenial + +for 5.5 +- ubuntu trusty + + ## Comparison to other distributions ## For tracking security release information, finding solutions for build errors @@ -193,4 +244,3 @@ are due to a bug in GCC which has been reported to GCC and will become fixed eventually: E array-bounds /??PKGBUILDDIR??/strings/decimal.c:300 (arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, sparc) E array-bounds /??PKGBUILDDIR??/strings/decimal.c:496 (arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, sparc) - -- GitLab