Eoan autopkgtest regressions - Migration Excuses

Bug #1840485 reported by Rafael David Tinoco on 2019-08-16
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bareos (Ubuntu)
Medium
Rafael David Tinoco

Bug Description

bareos mysql-all test is failing. This happens because the way the mysql test has been written. It looks like that, during reconfiguration, the database-type is reset to pgsql, instead of sticking to mysql like it should:

---- SCRIPT

Tests: mysql-all
Restrictions: needs-root allow-stderr
Depends:
 bareos,
 bareos-database-mysql,
 default-mysql-server | virtual-mysql-server,

---- SCRIPT

#!/bin/sh

set -e

# reinstall database in case mysql wasn't started early enough

service mysql start

echo 'bareos-database-common bareos-database-common/database-type string mysql' | debconf-set-selections
echo 'bareos-database-common bareos-database-common/database-type seen true' | debconf-set-selections
echo 'bareos-database-common bareos-database-common/dbconfig-reinstall boolean true' | debconf-set-selections
echo 'bareos-database-common bareos-database-common/dbconfig-reinstall seen true' | debconf-set-selections

dpkg-reconfigure bareos-database-common <---- HERE the database-type is reset

service bareos-dir restart

test/all

---- REPRODUCER

(c)root@tests:~$ echo 'bareos-database-common bareos-database-common/database-type string mysql' | debconf-set-selections

--

(c)root@tests:~$ echo 'bareos-database-common bareos-database-common/database-type seen true' | debconf-set-selections

--

(c)root@tests:~$ debconf-show bareos-database-common | grep database-type
* bareos-database-common/database-type: mysql

--

(c)root@tests:~$ DEBIAN_FRONTEND=noninteractive dpkg-reconfigure bareos-database-common
(config) dbc_go() bareos-database-common reconfigure 2171.
dbc_config() bareos-database-common reconfigure 2171.
dbc_set_dbtype_defaults() .
dbc_detect_installed_dbtype() pgsql.
_dbc_detect_installed_dbtype() pgsql.
dbc_detect_installed_dbtype() mysql.
_dbc_detect_installed_dbtype() mysql.
dbc_register_debconf() .
dbc_read_package_config() .
dbc_preseed_package_debconf() .
dbc_config() bareos-database-common reconfigure 2171.
dbc_set_dbtype_defaults() pgsql.
dbc_detect_installed_dbtype() pgsql.
_dbc_detect_installed_dbtype() pgsql.
dbc_detect_installed_dbtype() mysql.
_dbc_detect_installed_dbtype() mysql.
dbc_register_debconf() .
dbc_get_app_pass() .
dbconfig-common: writing config to /etc/dbconfig-common/bareos-database-common.conf
Replacing config file /etc/dbconfig-common/bareos-database-common.conf with new version
chown: invalid user: ‘postgres’
unable to connect to postgresql server.
error encountered creating user:
runuser: user postgres does not exist
dbconfig-common: bareos-database-common configure: noninteractive fail.
dbconfig-common: bareos-database-common configure: ignoring errors from here forwards
dbconfig-common: dumping pgsql database bareos to /var/tmp/bareos-database-common.bareos.2019-08-16-16.11.pgsql.pL2gNl.
dbconfig-common: dropping old pgsql database bareos.
populating database via sql... done.
dbconfig-common: flushing administrative password

-- ERROR

(c)root@tests:~$ debconf-show bareos-database-common | grep database-type
* bareos-database-common/database-type: pgsql

Changed in bareos (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Rafael David Tinoco (rafaeldtinoco)

(c)root@tests:~$ echo 'bareos-database-common bareos-database-common/database-type select mysql' | debconf-set-selections

(c)root@tests:~$ echo 'bareos-database-common bareos-database-common/database-type seen true' | debconf-set-selections

(c)root@tests:~$ DEBIAN_FRONTEND=noninteractive dpkg-reconfigure -u bareos-database-common
(config) dbc_go() bareos-database-common reconfigure 2171.
dbc_config() bareos-database-common reconfigure 2171.
dbc_set_dbtype_defaults() .
dbc_detect_installed_dbtype() pgsql.
_dbc_detect_installed_dbtype() pgsql.
dbc_detect_installed_dbtype() mysql.
_dbc_detect_installed_dbtype() mysql.
dbc_register_debconf() .
dbc_read_package_config() .
dbc_preseed_package_debconf() .
dbc_config() bareos-database-common reconfigure 2171.
dbc_set_dbtype_defaults() pgsql.

The function responsible for setting the "default_dbtype" is:

dbc_set_dbtype_defaults()

like when there is only one supported database installed:

        # Only one installed supported dbtype found, let's use it.
        if ! echo "$dbc_dbtypes" | grep -q "," ; then
            dbc_dbtype=$dbc_default_dbtype
        fi

but it should NOT define another default database if the dbconf option "database-type" has been "seen" already.

So.. dbconfig-common has this bug and should NOT redefine database-type if it has been already changed (seen) since the package has been installed and configured.

- bareos seems to be having problems with the new libglusterfs (yes, they broke API and functions now have diff arguments). There was an upstream discussion for QEMU, for example (https://bugzilla.redhat.com/show_bug.cgi?id=1684298) where Daniel Berrangé complains about the API changes and Kaleb replies they never promised to keep it (saying they change SO_VERSION/SO_NAME for that).

Note: This was late noticed because I was fixing the dbconfig-mysql regression showed in excuses page only, with the binary version AND build output NEVER showed anything related to gluster, weird ?! maybe its because build attempt is 153 days old ? Version is still the same :\ and debian/control asks for glusterfs.

- bareos-database-mysql and bareos-database-postgresql needed, each of them, dependency for either dbconfig-mysql or dbconfig-pgsql, or else dbconfig-common does not show the dbtype option during reconfiguration time (and that's why it was always sticking with pgsql, even for the mysql test).

I was able to make it work:

(c)root@tests:~$ systemctl status bareos-dir
● bareos-director.service - Bareos Director Daemon service
   Loaded: loaded (/lib/systemd/system/bareos-director.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-08-21 06:04:30 UTC; 2s ago
     Docs: man:bareos-dir(8)
  Process: 11604 ExecStartPre=/usr/sbin/bareos-dir -t -f (code=exited, status=0)
  Process: 11606 ExecStart=/usr/sbin/bareos-dir (code=exited, status=0)
 Main PID: 11607 (bareos-dir)
      CPU: 34ms
   CGroup: /system.slice/bareos-director.service
           └─11607 /usr/sbin/bareos-dir

Aug 21 06:04:30 tests systemd[1]: Starting Bareos Director Daemon service...
Aug 21 06:04:30 tests systemd[1]: Started Bareos Director Daemon service.

Using mysql... I think it also has something to do with authentication plugin..because I had to dpkg-reconfigure using dialog and set the sha256_password and then I could make bareos to work.

NOTE: At last resource, we can skip the tests and fix this as a SRU because I'm close to discover what is going on.

The debdiff I uploaded disables glusterfs due to incompatibility with new glusterfs being used in Eoan. I have also disabled all DEP8 tests but PGSQL (the only one working right now) and will fix after freeze if this gets uploaded in time.

The attachment "bareos_17.2.7-2ubuntu1.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Robie Basak (racb) wrote :

Hi Rafael,

Thank you for working on this!

I see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933019 for the glusterfs issue, making this FTBFS in sid. There's also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922344 for an autopkgtest regression. I'm not sure if that's the same issue as the one you're fixing here, but I think Debian also currently has your failure.

I suppose the dropping of glusterfs support is a feature change, but bareos isn't currently in the Eoan release pocket at all right now.

Is this worth doing all this disabling in Ubuntu right now, or would it be better to leave it for Debian to fix for possible inclusion in Ubuntu next cycle? Is it worth the delta, the risk of introducing broken not-Postgres support (due to it now being untested), without Debian's support (since they have this version of the package stuck in unstable), and with the ongoing maintenance burden for Ubuntu?

Some minor notes on your debdiff in case we decide to continue:

+ * Disable glusterfs support due to API changes
+ * Disable MySQL/SQLite DEP8 due to bad tests (LP: #1840485)

This makes it look like LP: #1840485 doesn't relate to "Disable glusterfs support" but it does. You could adjust the changelog entry to make this clear, but it's also difficult to link this bug to the Debian glusterfs bug so perhaps this bug needs splitting into two?

It's a useful technique when experimenting, but please avoid "commenting out" in final uploads. I see this as unnecessary cruft that others are forced to read through later, though I'm interested to hear if others disagree. The changelog will record that you removed those lines, and we can use a VCS, or simply debdiffs, if we want to restore them again later.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.