1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
# README for Debian packaging contributors
This documentation describes how to contribute to the official Debian packages
of MariaDB. The packaging in Debian repositories is not identical to the packaging
in mariadb.org repositories, but whatever is in Debian repositories will eventually
be upstreamed.
## Development environment and tools
Use a recent version of Debian or Ubuntu as the environment for Debian packaging
testing and development. Preferred environment is Debian Sid (unstable).
Install the tool used to manage and build the source:
sudo apt-get install git-buildpackage
## Getting the source
The official Debian package source is hosted on the Debian Gitlab server under
the MariaDB/MySQL packaging team at https://salsa.debian.org/mariadb-team/. You
are welcome to fork it and make merge requests.
To get the latest official Debian packaging source of mariadb-10.5, clone the
source repository with all relevant branches (master, upstream, pristine-tar) to
your local environment using _git-buildpackage_:
gbp clone --pristine-tar https://salsa.debian.org/mariadb-team/mariadb-10.5.git
If you have your own fork and SSH keys set up on Salsa, you can run:
gbp clone --pristine-tar git@salsa.debian.org:<username>/mariadb-10.5.git
The clone needs to be run only once. On later runs you can refresh your clone with
relevant branches using:
gbp pull --pristine-tar --force
## Building the packages
Build binaries, run testsuite and build Debian packages with:
gbp buildpackage
On the first run git-buildpackage will complain if some of the build dependencies
defined in debian/control are missing. Simply install those packages and run the
build again.
A quick command to install all dependencies:
sudo mk-build-deps -r -i debian/control -t "apt-get -y -o Debug::pkgProblemResolver=yes --no-install-recommends"
If the build fails, the easiest way to clean up before a new run is
git clean -fdx && git reset --hard
### Build options
If you want to skip the mysql-test-run step (which takes a lot of time) set
the following environment variable:
export DEB_BUILD_OPTIONS="nocheck"
If you want to run the build in parallel on 2 CPUs and have verbose output:
export DEB_BUILD_OPTIONS="parallel=2 verbose"
The options above can also be combined freely to get desired behavior.
### Using special build environments
If you want to ensure all build dependencies are clean, you can build inside a
Docker or sbuild (Debian tool) environment.
#### Build in Docker
First make a working directory for the build artifacts. Inside that directory
clone the repository. Then start a Docker session using whatever Debian/Ubuntu
image you want with the command:
docker run -it -v ${PWD}:/build -w /build debian:sid bash
This will start a session, where you are as the root user in the path /build
inside the Docker container. Here you can `cd` into the source directory,
install dependencies and start the build. Note that when you exit the session,
everything will be lost apart from the files you had inside the mounted volume
in `/build`.
#### Build using sbuild
If you prefer sbuild, you can build with something like:
gbp buildpackage --git-builder=sbuild -A -v -d unstable
## Creating a feature or bugfix branch
The repository has the following branch layout:
* upstream - contains the upstream source releases without modifications
* pristine-tar - contains extra delta needed to re-create the original
tarballs with the exactly same SHA-1 hash as the original tarballs by upstream
* master - packaging for Debian Sid (unstable)
* stretch - release branch for Debian 9 (stretch)
* buster - release branch for Debian 10 (buster)
* ubuntu-20.14 - release branch for Ubuntu 20.04 (focal)
* ubuntu-18.04 - release branch for Ubuntu 18.04 (bionic)
All new features and also bug fixes are done only in the master branch. The
release branches for Debian and Ubuntu are only used for security updates.
To prepare the Salsa pull request, create a bugfix branch from master with:
git checkout -b bugfix/NNNNNN-example-name
After this you can develop with all the usual git commit and push commands
until you have in your fork at Salsa the desired change and you are ready
to open the merge request.
### Notes about how to make changes in the proper way
First consider submitting your patch upstream. Upstream MariaDB makes frequent
maintenance releases and any fix done upstream will therefore be included in
Debian relatively quickly. You can send email to the developers mailing list
or open a pull request at https://github.com/MariaDB/server.
Follow these instructions if your fix is about packaging in Debian specifically.
Start by using `gitk --all` or similar tool to browse the previous changes. Try
to follow similar pattern in your new changes.
Keep in mind that all changes must done only for files residing in the `debian/`
sub-directory. If you need to create changes outside the `debian/` directory,
then you need to create a patch file using the same pattern as the patches
found in `debian/patches` and activated by a line in `debian/patches/series`.
Do not bundle in your commit any changes to `debian/changelog`. The correct
changelog entries will be created later by the maintainer using `git-dch` in an
automated fashion.
For an example of a patch adding commit see https://github.com/ottok/mariadb-10.0/commit/8d2a7c909
# Debug tips if build or test suite fails
## Debug build
A debug build can be created by adding the following build flags:
-DCMAKE_BUILD_TYPE=Debug \
-DMYSQL_MAINTAINER_MODE=OFF \
The latter flag ensures build does not stop on warnings but continues to the end.
## Debugging test suite failures
If the test suite is failing on Launchpad or some other CI system where you
don't have access to the build artifacts, you can extend the debian/rules file
to print out valuable information with the commands:
cd $(BUILDDIR)/mysql-test && find var/log/ -ls || true
cd $(BUILDDIR)/mysql-test && cat var/log/*.err || true
cd $(BUILDDIR)/mysql-test && tail -n 1000 var/log/*.log || true
The `cd` is required on every line since it is a Makefile and the actual command
needs to run in the correct directory. Also, the `|| true` at the end ensures
the build will complete and not abort if any of those debug steps fail.
If there is a core dump file a stack trace can be produced with:
cd $(BUILDDIR)/mysql-test && gdb --batch --ex 'thr a a bt' var/log/*/mysqld.1/core || true
## Debug installation/upgrade
To see what exactly the Debian maintainer scripts run, a verbose debug mode can be enabled with:
export DEBIAN_SCRIPT_DEBUG=1
apt install ...
The source files of the Debian maintainer scripts are not the final ones, as the package building stage may make changes and additions to them. To view a maintainer script in the final form run on installed system:
cat /var/lib/dpkg/info/mariadb-server-10.5.postinst
To review the my.cnf status you may run:
find /etc/mysql/ -ls
update-alternatives --display my.cnf
|
