Dear Maintainer,

I tried to upgrade mariadb-server-10.6 to mariadb-server 10.11.2-1, but it
failed with these errors (part of aptitude's output):

"""
Preparing to unpack .../mysql-common_5.8+1.1.0_all.deb ...
Unpacking mysql-common (5.8+1.1.0) over (5.8+1.0.8) ...
Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ...
Unpacking mariadb-common (1:10.11.2-1) over (1:10.6.11-2) ...
Preparing to unpack .../default-mysql-server_1.1.0_all.deb ...
Unpacking default-mysql-server (1.1.0) over (1.0.8) ...
(Reading database ... 331692 files and directories currently installed.)
Removing mariadb-server-10.6 (1:10.6.11-2) ...
dpkg: mariadb-server-core-10.6: dependency problems, but removing anyway as you requested:
 akonadi-backend-mysql depends on default-mysql-server-core | virtual-mysql-server-core; however:
  Package default-mysql-server-core is not installed.
  Package virtual-mysql-server-core is not installed.
  Package mariadb-server-core-10.6 which provides virtual-mysql-server-core is to be removed.

Removing mariadb-server-core-10.6 (1:10.6.11-2) ...
dpkg: warning: while removing mariadb-server-core-10.6, directory '/usr/share/mysql' not empty so not removed
Selecting previously unselected package mariadb-server-core.
(Reading database ... 331482 files and directories currently installed.)
Preparing to unpack .../mariadb-server-core_1%3a10.11.2-1_amd64.deb ...
Unpacking mariadb-server-core (1:10.11.2-1) ...
Preparing to unpack .../libmariadb3_1%3a10.11.2-1_amd64.deb ...
Unpacking libmariadb3:amd64 (1:10.11.2-1) over (1:10.6.11-2) ...
Preparing to unpack .../default-mysql-client_1.1.0_all.deb ...
Unpacking default-mysql-client (1.1.0) over (1.0.8) ...
dpkg: mariadb-client-10.6: dependency problems, but removing anyway as you requested:
 wordpress depends on default-mysql-client | virtual-mysql-client; however:
  Package default-mysql-client is not configured yet.
  Package virtual-mysql-client is not installed.
  Package mariadb-client-10.6 which provides virtual-mysql-client is to be removed.
  Package mariadb-client-10.5 which provides virtual-mysql-client is not installed.
  Package mariadb-client-10.3 which provides virtual-mysql-client is not installed.
 dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; however:
  Package default-mysql-client is not configured yet.
  Package virtual-mysql-client is not installed.
  Package mariadb-client-10.6 which provides virtual-mysql-client is to be removed.
  Package mariadb-client-10.5 which provides virtual-mysql-client is not installed.
  Package mariadb-client-10.3 which provides virtual-mysql-client is not installed.

(Reading database ... 331590 files and directories currently installed.)
Removing mariadb-client-10.6 (1:10.6.11-2) ...
dpkg: mariadb-client-core-10.6: dependency problems, but removing anyway as you requested:
 default-mysql-client-core depends on mariadb-client-core-10.6.

Removing mariadb-client-core-10.6 (1:10.6.11-2) ...
Selecting previously unselected package mariadb-client-core.
(Reading database ... 331476 files and directories currently installed.)
Preparing to unpack .../mariadb-client-core_1%3a10.11.2-1_amd64.deb ...
Unpacking mariadb-client-core (1:10.11.2-1) ...
Preparing to unpack .../default-mysql-client-core_1.1.0_all.deb ...
Unpacking default-mysql-client-core (1.1.0) over (1.0.8) ...
Selecting previously unselected package mariadb-client.
Preparing to unpack .../mariadb-client_1%3a10.11.2-1_amd64.deb ...
Unpacking mariadb-client (1:10.11.2-1) ...
Setting up mysql-common (5.8+1.1.0) ...
Setting up mariadb-common (1:10.11.2-1) ...
Selecting previously unselected package mariadb-server.
(Reading database ... 331590 files and directories currently installed.)
Preparing to unpack .../00-mariadb-server_1%3a10.11.2-1_amd64.deb ...
/var/lib/mysql: found previous version 10.6
Failed to stop mariadb.service: Unit mariadb.service not loaded.
invoke-rc.d: initscript mariadb, action "stop" failed.
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
Attempt to stop MariaDB/MySQL server returned exitcode 5
There is a MariaDB/MySQL server running, but we failed in our attempts to stop it.
Stop it yourself and try again!
dpkg: error processing archive /tmp/apt-dpkg-install-qINyMU/00-mariadb-server_1%3a10.11.2-1_amd64.deb (--unpack):
 new mariadb-server package pre-installation script subprocess returned error exit status 1
"""

So if I understand correctly, at the moment of unpacking the new mariadb-server,
there is no system-wide mariadb.service running or indeed any *.service file
present, but I did have akonadiserver running which spawns its own mysqld
process.  Thus the stop_server function in preinst fails as it does detect a
mysql process but 'invoke-rc.d mariadb stop' gives an error.

When I manually stopped akonadi's mariadb process, the upgrade went smoothly.
Is this actually intended behaviour?  If not this could be a more severe bug
than just 'normal'.  Not sure how the upgrade process works exactly, but I
suppose that I didn't run into this problem before as I was just upgrading
the existing package mariadb-server-10.6, instead of removing it and
replacing it by the new mariadb-server.

Thanks for maintaining!
-Steven

Hi!

Thanks for reporting this. What does the exact process listing look
like on a system that has the Akonadi server running?

What do these commands below yield on your system?

pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
pgrep -af "mysql|mariadb"

Indeed, the preinst has a section where it tries to stop any existing
servers. This section has been there for years and years, this is
nothing new in 10.11. Maybe it should have an extra check for Akonadi
in particular, or maybe some trigger for Akonadi to restart the
embedded MariaDB it has.

Hi Otto,

below the information you requested from my system:

pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
none

pgrep -af "mysql|mariadb"
1908 /usr/sbin/mysqld-akonadi --defaults-file=/home/rai/.local/share/akonadi/mysql.conf --datadir=/home/rai/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-rai.bxYrSB/mysql.socket --pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid

The problem has been described here first:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770

I will give an overview:
kontact (kmail, kalendar) does not work anymore

the akonadi error file shows:

org.kde.pim.akonadiserver: DATABASE ERROR:
org.kde.pim.akonadiserver:   Error code: "1292"
org.kde.pim.akonadiserver:   DB error:  "Incorrect datetime value: '2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1"
org.kde.pim.akonadiserver:   Error text: "Incorrect datetime value: '2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1 QMYSQL: Unable to execute query"
org.kde.pim.akonadiserver:   Query: "INSERT INTO PimItemTable (rev, remoteId, remoteRevision, gid, collectionId, mimeTypeId, datetime, atime, dirty, size) VALUES (:0, :1, :2, :3, :4, :5, :6, :7, :8, :9)"
org.kde.pim.akonadiserver: Error during insertion into table "PimItemTable" "Incorrect datetime value: '2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1 QMYSQL: Unable to execute query"

The culprit seems to be:
libmariadb3_1%3a10.3.38-0+deb10u1_amd64.deb

which has been updated on my system last Tuesday:
2023-02-21 07:30:26 upgrade libmariadb3:amd64 1:10.3.36-0+deb10u2 1:10.3.38-0+deb10u1

The next morning, kmail was broken.

If I understood it well, this was an upgrade from 10.3.36 to 10.3.38.

Paul did some research and it seems this commit to be the problem:

https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/773fb3e04ffae2b4868876be632fb7244329e7c3

Looking at the diff, I found the following change to
libmariadb/libmariadb/mariadb_lib.c:

@@ -3879,7 +3881,7 @@ int STDCALL mysql_set_server_option(MYSQL *mysql,

 ulong STDCALL mysql_get_client_version(void)
 {
-  return MARIADB_VERSION_ID;
+  return MARIADB_PACKAGE_VERSION_ID;
 }

BTW, I'm not using any oldstable stuff.
My sources.list looks like:

deb http://ftp.de.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.de.debian.org/debian/ buster main contrib non-free

deb http://security.debian.org/debian-security buster/updates main contrib non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib non-free

deb http://ftp.de.debian.org/debian/ buster-updates main non-free
deb-src http://ftp.de.debian.org/debian/ buster-updates main non-free

So it looks to me that whith a security update a functional change came in.

If I can help more, let me know.

Regards
Rai

Am 27.02.2023 um 06:46 schrieb Otto Kekäläinen:

Hey Otto

$ pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
362286
$ pgrep -af "mysql|mariadb"
362286 /usr/sbin/mysqld
--defaults-file=/home/username/.local/share/akonadi/mysql.conf 
--datadir=/home/username/.local/share/akonadi/db_data/ 
--socket=/run/user/1000/akonadi/mysql.socket 
--pid-file=/run/user/1000/akonadi/mysql.pid

The akonadiserver is controlled by
app-org.kde.kalendarac@autostart.service, so that's what I stopped for
the upgrade.  I don't use the KDE calendar or the rest of the KDE PIM
suite, so I don't know if it was really a good idea to just interrupt
this service.  I also have no clue how akonadi-backend-mysql would
handle mysqld/mariadbd upgrades.

Would it be a good idea to limit the search for running
mysqlds/mariadbds to those run by the mysql user (and perhaps root)?

Greetings
-Steven

Hi!
Not sure if that helps but there is also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031860 that seems to
be also relevant to that bug report.

Cheers!

So Rai has /usr/sbin/mysqld-akonadi from package akonadi-backend-mysql:

/usr/sbin/mysqld-akonadi
--defaults-file=/home/rai/.local/share/akonadi/mysql.conf
--datadir=/home/rai/.local/share/akonadi/db_data/
--socket=/tmp/akonadi-rai.bxYrSB/mysql.socket
--pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid

Rai was running Debian buster (=oldstable).

Steven has another version (Bullseye/stable?) with:

/usr/sbin/mysqld
--defaults-file=/home/username/.local/share/akonadi/mysql.conf
--datadir=/home/username/.local/share/akonadi/db_data/
--socket=/run/user/1000/akonadi/mysql.socket
--pid-file=/run/user/1000/akonadi/mysql.pid

The process detection indeed would be more robust if it checked for
owner 'mysql'. So we could switch it to run this instead?

pgrep -u root,mysql -x --nslist pid --ns $$ "mysqld|mariadbd"

Just need to be careful that this is run only on systems where the
user 'mysql' already exist, otherwise pgrep will return an error.


The issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770
Rai mentioned is unrelated. Let's not mix the discussion about that
into this one about the preinstall script process check.

Hi Otto,

Sry, it was my error - I'm indeed on debian buster here and referring to the bug #1031770.
I mixed it up.

Regards
Rai

Am 01.03.2023 um 08:13 schrieb Otto Kekäläinen:

(Adding akonadi-backend-mysql maintainers as recipients)

Hi!

When MariaDB Server upgrades, it could trigger a restart in
akonadi-backend-mysql, or the maintainer scripts could directly stop
the akonadi-backend-mysql. I am open to any solution here.

The main question is: what are the expectations from Akonadi on
MariaDB upgrades?

If MariaDB completely ignores Akonadi, you might run into problems
because Akonadi/mysqld did not have a clean shutdown on MariaDB 10.5
and then MariaDB 10.11 will fail to start because crash recovery
across major versions. Before going into major version upgrade the old
server needs to be stopped gracefully with for example `pkill mysqld`
(or a more elaborate version matching other binary names and checking
for process owning user etc). If MariaDB stops the server something
needs to exist to restart it.

Merge Requests on Salsa against
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.preinst#L27-47
are welcome!

This is still waiting for input from Akonadi maintainers:
And side note: the libmariadb3 issue was reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031773,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031860 and
forwarded upstream in
https://lists.launchpad.net/maria-discuss/msg06508.html

I've been thinking trying to come up with some good solutions.

But this does not as such seem to be akonadi specific; it could also happen in
a case where a system administrator runs a custom mariadb instance managed as
a different instance than what the mariadb/mysql stop scripts handles.

I do though think that the akonadi instance is more likely.

I think that - in order fix both; basically error out not only if the invoke-
rc.d calls fail, but if there are any running mariadb instances left on the
system and let the system administrator deal with it.

That will probably cover most issues. Except the one I ran into*
I think it is the best we can do for now.

If I had a infinite wishlist, it would be to let newer mariadb's be able to
also fix older setups, or a separate tool being able to do that.

/Sune


* I had a desktop system lockup for unknown reasons; rebooted and didn't login
as me, but rather dropped into a VT and did a upgrade, then rebooted and
logged in.  I ended up debootstrapping a slightly older chroot with a slightly
older mariadb, bindmounting the mariadb datadirs into it, launching and
stopping mariadb inside it. unmounting and removing.

The difference is that if a sysadmin manually has built some custom
thing and runs it, they will know about it and are likely able to fix
it.

In this case the server is run automatically by the Akonadi package.
Thus the Akonadi package should do something about the server
stop/starts automatically. Surely the Akonadi package has some
facility that starts/stops the server? What is that facility? Can we
call it from the MariaDB server preinstall script to shut it down, and
from the postinstall script to start up again?

It is a user process run in a user session, so it is not something the package
maintainers should touch.

But akonadictl stop  for all users in question would do it. Then remember
which users you did it for, and akonadictl start afterwards for those users

But I would expect that to end up as a severe policy violation; I don't have a
reference handy though.

Also be aware that the users mail client, calendar app and similar will be
greyed out and text on top : "Akonadi  not running" and then a giant button in
the middle that says "start akonadi" tempting users to press it. And it does
what it says on the tin.

/Sune

Hey,

can you explain, why this is now an issue and wasn't for several Debian
versions? As I package Akonadi for a while now I never had issues with Mariadb
upgrades.

I know from Postgres that you need to have both version installed ( old+new)
to make a successfully upgrade, wouldn't that be a possible solution for
MariaDB too? So that you do not remove the old mariadb-server version when
installing the new one? Than a user can re-login and everything is fine.
processes.

Regards,

hefee

PS: sorry I'm not a lot on my PC the last weeks.

Hi!

I suggested in my mail on Feb 28th to have this in the MariaDB preinstall:

    pgrep -u root,mysql -x --nslist pid --ns $$ "mysqld|mariadbd"

It would safely shut down the Akonadi server before MariaDB goes into
update and the binary it uses vanishes for a while.

However I never got any confirmation/support for this, so I didn't
proceed with it.


If you want to contribute in the open source way to fix this or any
other issue, see
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian
on how to submit a Merge Request!

The places you would want to modify are:
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.preinst#L31
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.postrm#L17

Hello,

Bug #1032047 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/25d7ea8064323dd846a03bab08038d8a61170d35
If a random user has their own copy of mysqld/mariadbd running, the dpkg
maintainer script should not care about it.
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1032047

Hello,

Bug #1032047 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/2c76cf39dbcb36bf3a5f1b9b09d4e25e3325c72b
If a random user has their own copy of mysqld/mariadbd running, the dpkg
maintainer script should not care about it.
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1032047

Hello,

Bug #1032047 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/38198d0b9e1c7821ddd074e308b25034bdcdce5b
If a random user has their own copy of mysqld/mariadbd running, the dpkg
maintainer script should not care about it.
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1032047

Hello,

Bug #1032047 in mariadb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/38198d0b9e1c7821ddd074e308b25034bdcdce5b
If a random user has their own copy of mysqld/mariadbd running, the dpkg
maintainer script should not care about it.
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1032047

We believe that the bug you reported is fixed in the latest version of
mariadb, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1032047@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Otto Kekäläinen <otto@debian.org> (supplier of updated mariadb package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 25 Mar 2023 23:26:42 -0700
Source: mariadb
Binary: libmariadb-dev libmariadb-dev-compat libmariadb3 libmariadbd19 libmariadbd-dev mariadb-common mariadb-client-core mariadb-client mariadb-server-core mariadb-server mariadb-backup mariadb-plugin-connect mariadb-plugin-s3 mariadb-plugin-rocksdb mariadb-plugin-oqgraph mariadb-plugin-mroonga mariadb-plugin-spider mariadb-plugin-gssapi-server mariadb-plugin-gssapi-client mariadb-plugin-cracklib-password-check mariadb-plugin-hashicorp-key-management mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy mariadb-test mariadb-test-data
Architecture: source
Version: 1:10.11.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
Changed-By: Otto Kekäläinen <otto@debian.org>
Description:
 libmariadb-dev - MariaDB database development files
 libmariadb-dev-compat - MariaDB Connector/C, compatibility symlinks
 libmariadb3 - MariaDB database client library
 libmariadbd-dev - MariaDB embedded database, development files
 libmariadbd19 - MariaDB embedded database, shared library
 mariadb-backup - Backup tool for MariaDB server
 mariadb-client - MariaDB database client binaries
 mariadb-client-core - MariaDB database core client binaries
 mariadb-common - MariaDB common configuration files
 mariadb-plugin-connect - Connect storage engine for MariaDB
 mariadb-plugin-cracklib-password-check - CrackLib Password Validation Plugin for MariaDB
 mariadb-plugin-gssapi-client - GSSAPI authentication plugin for MariaDB client
 mariadb-plugin-gssapi-server - GSSAPI authentication plugin for MariaDB server
 mariadb-plugin-hashicorp-key-management - Hashicorp Key Management plugin for MariaDB
 mariadb-plugin-mroonga - Mroonga storage engine for MariaDB
 mariadb-plugin-oqgraph - OQGraph storage engine for MariaDB
 mariadb-plugin-provider-bzip2 - BZip2 compression support in the server and storage engines
 mariadb-plugin-provider-lz4 - LZ4 compression support in the server and storage engines
 mariadb-plugin-provider-lzma - LZMA compression support in the server and storage engines
 mariadb-plugin-provider-lzo - LZO compression support in the server and storage engines
 mariadb-plugin-provider-snappy - Snappy compression support in the server and storage engines
 mariadb-plugin-rocksdb - RocksDB storage engine for MariaDB
 mariadb-plugin-s3 - Amazon S3 archival storage engine for MariaDB
 mariadb-plugin-spider - Spider storage engine for MariaDB
 mariadb-server - MariaDB database server binaries
 mariadb-server-core - MariaDB database core server files
 mariadb-test - MariaDB database regression test suite
 mariadb-test-data - MariaDB database regression test suite - data files
Closes: 866751 1029165 1032047 1032860 1032861
Changes:
 mariadb (1:10.11.2-2) unstable; urgency=medium
 .
   [ Otto Kekäläinen ]
   * SUMMARY: This version has a lot of bug fixes, quality fixes, documentation
     and translation updates and it is tailored for the Debian 12 "Bookworm"
     release and all potentially functional changes have been left out and
     are pending review and merge post-Bookworm release at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests,
     where contributions both as reviews and new submissions are welcome!
   * Update NEWS to summarize what is new in MariaDB 10.11 (compared to 10.6)
   * Update and activate configuration tracing in autopkgtests to ensure that
     for the Debian 12 "Bookworm" release cycle no upstream server config change
     would slip in unnoticed
   * Enable mariadb-plugin-rocksdb for riscv64 (fixes autopkgtests for riscv64)
   * Sync downstream (where applicable) with upstream 10.11 debian/* contents
     so that using diff/meld to compare changes are easier
   * Add important upstream 10.11.2+ fixes as packes:
     * Stack overflow in pinbox allocator (PR#2541)
     * Upgrades from MySQL 5.7 to MariaDB 10.11 (MDEV-30483) (Closes: #866751)
     * Misc compiler warnings in upstream build
     * Incomplete stack traces if MariaDB crashes
     * Make mariadbd emit warnings if mariadb-upgrade was not run
     * Binlog failures due to 'character_set_client' (MDEV-30824)
   * Prevent mariadb-test-run from using native I/O on ppc64el and s390x due to
     Linux kernel bug (Related: #1031656)
   * Add patch to better diagnose potential failures in main.order_by_innodb
   * Add patch to fix cross-compilation failure on uca-dump (Closes: #1029165)
   * Update mariadb-test-run skip test lists to not run tests that are known
     to be broken or unstable, and that have been reported upstream
   * Limit check of running mysqld/mariadbd to system users (Closes: #1032047)
   * Make error more helpful in case server restart fails (Related: #1033234)
   * Update Lintian overrides after rigorous review of all Lintian issues
     * Remove incorrect Multi-Arch definitions
     * Fix man pages syntax issues (Closes: #1032861)
     * Fix spelling in MariaDB and components (Closes: #1032860)
     * Refresh patches metadata
     * Update upstream signing key
     * Fix dependency of obsolete libncurses5-dev
 .
   [ Ekaterine Papava ]
   * Add Georgian translation (error messages)
 .
   [ Tuukka Pasanen ]
   * Update README files to correct versions
Checksums-Sha1:
 37b5c369db39f34488c679b12f607a0b264af5ce 5213 mariadb_10.11.2-2.dsc
 a93c6575d83cec0e6ea19758435f4ed8e3089f1d 398748 mariadb_10.11.2-2.debian.tar.xz
 8993b3b3672d22db920196384bde29012b86869c 9522 mariadb_10.11.2-2_source.buildinfo
Checksums-Sha256:
 5f3615a973491de1ec9f97a58af9849cfcb47e7c3a158564a6cfd6e619d7ec89 5213 mariadb_10.11.2-2.dsc
 8f89e3148733803b307b5512767220605c6b0f4ef15fc76131a582ffc56cc656 398748 mariadb_10.11.2-2.debian.tar.xz
 328f11b5ef17b2d4596b85d0672a2c877a031a3039bf48bd3289a741372e99fb 9522 mariadb_10.11.2-2_source.buildinfo
Files:
 78b23e72f246bec4d9703c4022d3821f 5213 database optional mariadb_10.11.2-2.dsc
 fe8d13be441a034d9345dcb81f14ba37 398748 database optional mariadb_10.11.2-2.debian.tar.xz
 80f8b305ef9f19ced6d65c42307f7f4e 9522 database optional mariadb_10.11.2-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmbRSsR88dMO0U+RvvthEn87o2ogFAmQf8DkACgkQvthEn87o
2ojGwA//eUaKD17uLWh9Z80ASSnlJCEm6ghnkwhCdXvJrr2CjA+BEbsX2v/McMRi
y4EsD500yVbFo5Zn52DaQK/c7+IgEwolGqnMRXtnjl0yJ84ghNPG0zRdsCBEdDnG
J4DOYJbRTSJvjPDZox98vXps3nYXuczJMJ1OipJzkxzHWWkG9eYwXFClatr50vnU
5HSU5Slt/2TzfW0HwA4+RN7XrVBqsFWyTJaJiGc0or/iwhlm1kW5FbY/ws8dffkL
NGxGLQRUElz0yyJ8DTlBk/3EklZM2rb2zcOrgFw9TW24V3vpejmsy+S34oPBdZUD
27XHGmGhy1fkuA3iN+S7NUMWrQD72yvAG2m8nny3gE1hEebO2wUlv+7s2Nsykkjp
UVDOLKR3TMMJHlFxZP8gGXyUSr6aQNmMLasp7iuz4MzgaMYYqhnol058OVq1mKVR
3ExggTQ8RbIdzEpadO1naX0DASLtnsOeD8E6xp05d5gwrDiDPjc0c/+nE4E3ETyZ
Dsuwrz0XCs1kUV/TIKCc0TjXXsRDuafBQSa6dbTtyKPUv8kOHLALrmoSgd2iohdo
GMrhTRNuQPQwS4huxCs1oZnOUy8+0vqrjhElgxa7RaPHe+3zu4qkYjSeLso3+kzZ
MwSZZTx1Zjg1YGhsTzj4sqwWiZ8QxDHHHyYSKs7tmhhGHg+p9CE=
=TZ6v
-----END PGP SIGNATURE-----