Current Debian package revision scheme when using
debian/autobake-deb.sh script is:
'1:VERSION+maria~LSBNAME'
For example if VERSION can be like 10.6.8 and LSBNAME is
buster then version and revision is:
'1:10.6.8+maria~buster'
Which can lead to problem as distro code names can be lexical unordered.
For example Debian LSBNAME's can be:
Codename Buster is Debian version 10
Codename Bookworm is Debian version 11
This happens because in ASCII table
Buster first two digits are 'Bu' and they are in hex 0x42 and 0x75
and Bookworm first digits 'Bo' are they are in hex 0x42 and 0x6F
When apt is upgrading it means that:
1:10.6.8+maria~buster is bigger than 1:10.6.8+maria~bookworm
and that leads to problems in dist-upgrade process
To solve problem revision format is changed to:
'1:VERSION+maria~(deb|ubu)LSBVERSION'
Example for Debian 11 is now:
1:10.6.8+maria~deb11
and for Ubuntu 22.04 is now:
1:10.6.8+maria~ubu2204
There are new Variables
* VERSION which contains whole version string
* LSBVERSION which contains LSB version of distro
* LSBID which contains LSB ID (Debian or Ubuntu)
added to debian/autobake-deb.sh.
Also CODENAME is change to LSBNAME as it's more declaritive
Remove version suffix from Debian packages (for example mariadb-server-10.9)
because installing suffixed package removes older version
of package even if it's suffixed (for example mariadb-server-10.7)
This make also Debian package management easier in future MariaDB
version iterations because there is no need for stacking
Conlicts/Breaks/Replaces-parameters in every new major release
The autopkgtest was failing due to missing *.changes file. This is part
of source build, so revert autobake-deb.sh back to NOT using -b for
Gitlab-CI/Salsa-CI runs.
Add requirement in Debian control file for libfmt 7.0
which is needed for building MariaDB.
This supports the SFORMAT function added in MDEV-25015.
+ autobake-deb.sh so old Debian/Ubuntu still
bundle the libfmt pulled in from upstream.
Closes#2062
While moving to a prescribed dependencies in MDEV-28011, an error was made
in the merge. The Ubuntu and Debian supported architectures of rocksdb-tools
are different and need to be treated as such.
This actually had no effect as our support of mariadb-plugin-rocksdb was never
different to the distro support of rocksdb-tools. Some notes where added
to this affect.
There is also nothing to do for Debian sid, and never should be.
The differentiation and grouping of distro codenames is for convenience in
merging upwards as more dependencies change across distro versions.
The fixing of versions rather than relying on apt-cache to be correct prevents
unstable changes between releases, and potentially uninstallable packages like
happened in MDEV-28014.
Correct comment about zstd to MDEV-16525
commit '6de482a6fefac0c21daf33ed465644151cdf879f'
10.3 no longer errors in truncate_notembedded.test
but per comments, a non-crash is all that we are after.
Travis is dead to us so we don't need all the conditions around it.
Remove depends for no longer supported versions
Debian Jessies, and Ubuntu Trusty, Xenial, Wily are all eol
as far as we are concerned.
The dependancy on an apt cache when running autobake broke the
10.2 aarch64 packages (MDEV-28014). Lets reduce the risk here.
zstd-1.1.3 is needed however stretch has only 1.1.2.
Move to distro version based checks as checks against the
apt-cache are unreliable if there is no cache.
Debian stretch is supported until Jun 2022.
MyRocks definitavely does require 1.1.3+.
Mroonga has never been zstd enabled, though
support for it exists in the codebase.
While a 1.1.3+ version exists in stretch backports
we don't support this.
Fixes: b67210b105
The debian/salsa-ci.yml used to work also on upstream MariaDB.org branches,
but has recently regressed and several jobs stopped working. These fixes
are necessary to get it working again.
* Partially revert 8642f592 that never worked, as MariaDB 10.2 does not
have a mysql.global table nor a mariadb.sys user. Those features weren't
introduced until MariaDB 10.4.
* Partially revert 0268b871 as we don't want ColumnStore as part of the
native Debian build. It should build only when the build is triggered
via autobake-deb.sh (MariaDB.org builds).
* Adjust salsa-ci.yml to cope with various Stretch to Sid upgrade issues
and remove the legacy mariadb-connector-c job completely as that package
hasn't been around for years anymore.
* Extend Lintian overrides to be otherwise Lintian clean
This corrects the autobake on Stretch
Caused by commit 0268b87122
and commit 3d16e0e16c.
For very strange reasons (still a mistery) the above commits caused the
federatedx, archive and blackhole plugins to be missing in the
install location even though they where built in the build log.
This only occured on Stretch and not recent Ubuntu and Debian
distros.
The stretch autobake output contained:
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_archive.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_archive.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_blackhole.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_blackhole.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_federatedx.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_federatedx.sodh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_archive.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_archive.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_blackhole.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_blackhole.so
dh_install: Cannot find (any matches for) "usr/lib/mysql/plugin/ha_federatedx.so" (tried in "." and "debian/tmp")
dh_install: mariadb-server-10.5 missing files: usr/lib/mysql/plugin/ha_federatedx.so
Columnstore badly failed on 32bit. The way Debian triggers
somehow doesn't detect the amd64 in the architecture of columnstore
so we explicitly disable it to prevent failures on x86_32.
The architecture from the control file is sufficient to not build
of arm64 and other unsupported achitectures so we don't need to
disable columnstore by default.
The logic around not building columnstore on Travis/Gitlab ci
can be preserved with a autobake-deb.sh restructure.
* Clean up autobake-deb.sh
- No need to define any TokuDB rules, there is no such package
- No need to define RocksDB arch, it already has "Architecture:" line
- No need to dh-systemd backwards compat stanza, neither Debian Jessie
nor Ubuntu Xenial has any new MariaDB 10.5 releases anymore
- Minor spelling fixes
* Ensure dch runs non-interactively so builds pass with new dch version
A recent version of dch (available in Ubuntu Hirsute and Debian Bullseye)
had a change in behaviour that it started prompting if the DEBEMAIL or
EMAIL variable as unset, asking for confirmation. We can't have anything
interactive in our build scripts, so prevent this prompt by giving
--controlmaint to the command, so it always uses the name and email from
the debian/control file and does not prompt anything.
The command-line argument has been around for a long time, so it is safe
to use on all Debian/Ubuntu builds we have.
See https://manpages.debian.org/jessie/devscripts/dch.1.en.html
Since MariaDB 10.5 is the oldest release we still release for Ubuntu Hisute
and Debian Bullseye, merge this on 10.5 and from there merge up to latest.
No need to consider 10.2, 10.3 and 10.4 as those will not be released for
Ubuntu Bullseye or Ubuntu Hirsute.
* Minor Salsa-CI cleanup
- Fix spelling (synced from downstream Debian)
* Many minor spelling fixes (synced from downstream Debian)
Keep the readline installation step in Salsa-CI stages that install
MariaDB.org packages in Debian Sid (or releases after is, such as
Debian 11 "Bullseye" or Ubuntu 21.04 "Hirsute") as those old packages
still depend on readline for the MariaDB Server itself.
MariaDB Server still supports Ubuntu 16.04 "Xenial" until it goes EOL
in April 30, 2021. Thus we need to include a customization for backwards
compatibility.
This change is intended to be applied for all MariaDB versions still
supported, i.e. 10.2 to 10.6.
Updating the debian/control file will automatically update the dependencies
in all CI environments that directly read the debian/control file, such
as Salsa-CI and buildbot.mariadb.org to some degree.
(https://github.com/MariaDB/mariadb.org-tools/issues/43)
On Debian/Ubuntu releases that don't have libpmem-dev available,
automatically omit it.
Debian/Ubuntu availability visible at:
- https://packages.debian.org/search?searchon=names&keywords=libpmem-dev
- https://packages.ubuntu.com/search?searchon=names&keywords=libpmem-dev
Also modify debian/rules to activate the use of PMEM, as it does not seem
to activate automatically.
The scope of this change is also Debian/Ubuntu only. No RPM or Windows or
Mac changes are included in this commit.
This commit does not update the external libmariadb or ColumnStore
CI pipelines, as those are maintained in different repositories.
