Dear Maintainer,

I ran into a problem on upgrading an installation of mailman3 during
a Debian system update from bullseye to bookworm.

After the upgrade, the default/installed cron jobs at the hour level
started throwing errors:

[ -f /usr/bin/django-admin ] && flock -n /var/run/mailman3-web/cron.hourly /usr/share/mailman3-web/manage.py runjobs hourly

[ERROR/MainProcess] Failed indexing 1 - 1 (retry 5/5): (1054, "Unknown column 'hyperkitty_mailinglist.archive_rendering_mode' in 'field list'") (pid 2307): (1054, "Unknown column 'hyperkitty_mailinglist.archive_rendering_mode' in 'field list'")
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/db/models/fields/related_descriptors.py", line 173, in __get__
    rel_obj = self.field.get_cached_value(instance)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/django/db/models/fields/mixins.py", line 15, in get_cached_value
    return instance._state.fields_cache[cache_name]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'mailinglist'

I got a similar error in the logs when I tried to use the web UI to
poke around the hyperkitty settings.  After some random websearches I
took a guess and ran:

# cd /usr/share/mailman3-web
# python3 manage.py migrate
Operations to perform:
  Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount
Running migrations:
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying django_q.0010_auto_20200610_0856... OK
  Applying django_q.0011_auto_20200628_1055... OK
  Applying django_q.0012_auto_20200702_1608... OK
  Applying django_q.0013_task_attempt_count... OK
  Applying django_q.0014_schedule_cluster... OK
  Applying hyperkitty.0022_mailinglist_archive_rendering_mode... OK
  Applying hyperkitty.0023_alter_mailinglist_name... OK

Running this resolved the errors.  It's possible the problem here was on
my end (as noted by `mailman3/dbconfig-install: false` in this report) -
the dpkg configuration question sounded like I should choose 'no' if I
had previously set up a database, which of course coming from a working
bullseye installation I had.

Ideally this would have run as part of the package upgrade.

I also got a number of warnings that I was able to clean up easily
enough, this was the only hard error that appeared to break
functionality.  Let me know if there is interest and I can file bugs for
those.  It's possible/probable that they've been dealt with upstream -
this felt like the only Debian specific issue.