Strangely, on sid the dist-upgrade actually works:
http://buildbot.askmonty.org/buildbot/builders/kvm-deb-sid-amd64/builds/2392/steps/test_3/logs/stdio

The following NEW packages will be installed:

  libmariadb3

The following packages will be upgraded:

  libmariadbclient18 libmysqlclient18 mariadb-client-10.2

  mariadb-client-core-10.2 mariadb-common mariadb-server mariadb-server-10.2

  mariadb-server-core-10.2 mysql-common

9 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Did you recently (1-5 days) do some changes to buildbot?

At http://buildbot.askmonty.org/buildbot/grid?branch=ok-debpkg-10.2&category=main&category=experimental the jessie and wheezy tests pass at commit 779d416a992f (my last change to 10.2) but then has started to fail after other people's commits, but none of the commits are Debian packaging related, so it made me think if buildbot tests themselves have changed.

Yes, the history is currently a bit confusing, sorry about that, let me clarify.

We have had dist-upgrade test (the one that upgrades from 10.2.2 to current 10.2 packages) for a while. It's logic is this:

• install latest released 10.2 packages;
• execute a few queries, store the version number, the list of installed engines and the list of installed plugins;
• change the repo to point at the current packages, run dist-upgrade;
• make sure that the server is running, execute a few queries, store the version number, the list of installed engines and the list of installed plugins;
• compare the lists of installed engines before and after the upgrade (they must be identical);
• compare the lists of installed plugins before and after the upgrade (currently disabled for 10.2 until XtraDB 5.7 is merged);
• compare the version numbers, they must be different, in order to make sure that the upgrade has happened.

So, this last part is the culprit. It was disabled before, because it produced too many false-positives (e.g. when the version number wasn't raised in time after a release, or when a development tree was based on a version which was already released etc.). It was still printing the version numbers into the output, but it didn't compare them and didn't fail when the version didn't change.

While looking into something else, I discovered that the upgrade actually didn't work on some versions, so I filed a bug and re-enabled the check, which is why it started failing now. svoj was also notified.

So, the builders, builds or test flow didn't change, but the pass/fail criteria have changed.

If needed, I can go manually back through builds and outputs and find out when the upgrade stopped happening.

I am unable to reproduce this. I repeated manually the steps visible at http://buildbot.askmonty.org/buildbot/builders/kvm-deb-jessie-amd64/builds/1403/steps/test_3/logs/stdio but I don't see the same result.

I installed on a fresh Jessie install MariaDB 10.2 from deb http://mirror2.hs-esslingen.de/mariadb/repo/10.2/debian jessie main and then activated deb http://hasky.askmonty.org/archive/10.2/build-12044/kvm-deb-jessie-amd64/debs/ binary/ after which both dist-upgrade and normal upgrade work as expected, updating also the server.

# DEBIAN_FRONTEND=noninteractive MYSQLD_STARTUP_TIMEOUT=180 apt-get dist-upgrade --allow-unauthenticated -y

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Calculating upgrade... The following package was automatically installed and is no longer required:

  libmariadbclient18

Use 'apt-get autoremove' to remove it.

Done

The following NEW packages will be installed:

  libmariadb3 libterm-readkey-perl

The following packages will be upgraded:

  libmariadbclient18 libmysqlclient18 mariadb-client-10.2 mariadb-client-core-10.2 mariadb-common mariadb-server mariadb-server-10.2 mariadb-server-core-10.2 mysql-common

9 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.

Need to get 11.1 MB of archives.

After this operation, 6,175 kB disk space will be freed.

WARNING: The following packages cannot be authenticated!

  mysql-common mariadb-common mariadb-server mariadb-client-core-10.2 mariadb-server-10.2 mariadb-server-core-10.2 libmysqlclient18 libmariadbclient18 libmariadb3

  mariadb-client-10.2

Authentication warning overridden.

Get:1 http://http.debian.net/debian/ jessie/main libterm-readkey-perl amd64 2.32-1+b1 [28.0 kB]

Get:2 http://hasky.askmonty.org/archive/10.2/build-12044/kvm-deb-jessie-amd64/debs/ binary/ mysql-common 10.2.3+maria~jessie [8,504 B]

Get:3 http://hasky.askmonty.org/archive/10.2/build-12044/kvm-deb-jessie-amd64/debs/ binary/ mariadb-common 10.2.3+maria~jessie [3,420 B]

Get:4 http://hasky.askmonty.org/archive/10.2/build-12044/kvm-deb-jessie-amd64/debs/ binary/ mariadb-server 10.2.3+maria~jessie [3,028 B]

Get:5 http://hasky.askmonty.org/archive/10.2/build-12044/kvm-deb-jessie-amd64/debs/ binary/ mariadb-client-core-10.2 10.2.3+maria~jessie [733 kB]

Get:6 http://hasky.askmonty.org/archive/10.2/build-12044/kvm-deb-jessie-amd64/debs/ binary/ mariadb-server-10.2 10.2.3+maria~jessie [3,653 kB]

11% [6 mariadb-server-10.2 480 kB/3,653 kB 13%]^C

I tried it manually before filing the report, it failed for me back then. I'll check again.

Side note dbart: You might want to run on the image apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db to avoid have unnecessary warnings in the log about W: GPG error: http://mirror2.hs-esslingen.de jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY CBCB082A1BB943DB

elenst Can I download the exact jessie image buildbot uses from somewhere so I could try to reproduce the error with it instead of a generic jessie image?

Can I download the exact jessie image buildbot uses from somewhere so I could try to reproduce the error with it instead of a generic jessie image?

otto, it's not going to be easy. I'm re-trying it manually now, not quite certain yet what's happening – sometimes it passes, sometimes it fails, I need to find the pattern. As soon as I do, I'll paste everything that I have, and if it's not enough, we'll see what we should do next.

otto,

I've just realized what must have been different in your scenario, and what must be the reason of the problem with dist-upgrade.

In order to keep dist-upgrade limited to MariaDB only, to avoid lengthy system-wide upgrades, after initial installation the test removes from sources.list everything, except for the local repo. Normally it works fine, because a previous minor version has already been installed. So, it also serves as an additional check that no new dependencies have been introduced, because normally a minor upgrade should not bring any.
But 10.2.3 did (I think it's allowed to since it's still beta), it wants libnuma1, which cannot be installed without default repos, hence the problem. When I add the default repo back, it works all right. So, dist-upgrade is a configuration problem after all; speaking of which, I would appreciate some advice on whether it's possible to limit dist-upgrade to certain packages only in a smarter way than disabling all other repos?

However, it doesn't explain the problem with 10.1=>10.2 upgrade, I will look into it next.

svoj, FYI.

otto,

10.1 => 10.2 upgrade problem (install 10.2 server over the existing 10.1) is still reproducible without any tricks with repos; does it happen on your machine?

However, it's not new, looks the same with 10.2.2. I will update the description and decrease the priority since 10.1=>10.2 is a less critical problem at the moment than 10.2=>10.2. Of course, it will become critical when we're closer to the GA.

Everything passes in http://buildbot.askmonty.org/buildbot/builders/kvm-deb-stretch-amd64/builds/38 (10.1 -> 10.2 upgrade in http://buildbot.askmonty.org/buildbot/builders/kvm-deb-stretch-amd64/builds/38/steps/test_2/logs/stdio)

I fixed this yesterday as a by product of fixing systemd issue.