retitle 847277 django migrations in jessie require django from jessie-backports to upgrade to stretch severity 847277 normal affects 847277 python-django thanks
On Wed, 08 Feb 2017 14:48:21 +0100 Andreas Beckmann <a...@debian.org> wrote: > Followup-For: Bug #847277 > Control: found -1 2016.12-1 > Control: tag -1 - unreproducible > Control: severity -1 serious The flow needs to go via jessie-backports, just like any django project in jessie as the database migrations from jessie cannot be handled by django1.10 without going via the LTS release, django1.8. The bug, if any, is in django1.7 which does not (cannot) know how to handle database migrations the way that django1.8 (and subsequent releases) need to handle migrations. However, that change can't be backported to jessie except by using the new flow from 1.8 which breaks all other packages using django in jessie. On a real instance, the postgres cluster would also need to be migrated. If piuparts cannot handle such upgrades, that must be a bug in piuparts. We test this regularly, albeit to the newer version in our staging repo rather than the version in stretch. https://staging.validation.linaro.org/scheduler/job/162057/definition#defline59 # on jessie, with backports enabled: DEBIAN_FRONTEND=noninteractive apt-get -y install lava-dispatcher lava-server .... apt -q -y -t jessie-backports install python-django-kvstore python-django python-django-tables2 lava-server # now proceed with the upgrade. DEBIAN_FRONTEND=noninteractive apt -y upgrade DEBIAN_FRONTEND=noninteractive apt -y dist-upgrade (alternatively, admins can just install python-django python-django-tables2 from jessie-backports and run `lava-server managedb migrate` manually.) There's nothing wrong AFAICT with requiring a step via jessie-backports. There is also nothing LAVA can do about this, it's a django issue which cannot be fixed in jessie as there are other packages in jessie which are not compatible with django1.8 LTS (including the version of LAVA in jessie). https://staging.validation.linaro.org/scheduler/job/163429 https://staging.validation.linaro.org/scheduler/job/163429/definition#defline59 Users are already aware of this: https://lists.linaro.org/pipermail/lava-announce/2016-June/000010.html > Control: retitle -1 lava-server: fails to upgrade from jessie to > stretch: InconsistentMigrationHistory: Migration > lava_scheduler_app.0001_initial is applied before its dependency > linaro_django_xmlrpc.0001_initial on database 'default' > > The problem is also reproducible on a plain jessie->stretch upgrade: The problem would only apply on a jessie-> stretch upgrade without upgrading django using jessie-backports. > > https://piuparts.debian.org/jessie2stretch/fail/lava-server_2016.12-1.log > > [...] > Setting up lava-server (2016.12-1) ... > Installing new version of config > file /etc/apache2/sites-available/lava-server.conf ... Installing new > version of config file /etc/init.d/lava-server ... Installing new > version of config file /etc/lava-server/settings.conf ... lavaserver > lavaserver > devel > devel > System check identified some issues: > > WARNINGS: > va_scheduler_app.Notification.job_status_trigger: (fields.W901) > CommaSeparatedIntegerField has been deprecated. Support for it > (except in historical migrations) will be removed in Django 2.0. > HINT: Use > CharField(validators=[validate_comma_separated_integer_ceback (most > recent call last): File "/usr/bin/lava-server", line 78, in <module> > main() File "/usr/bin/lava-server", line 74, in main > execute_from_command_line(django_options) File > "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", > line 367, in execute_from_command_line utility.execute() File > "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", > line 359, in execute > self.fetch_command(subcommand).run_from_argv(self.argv) File > "/usr/lib/python2.7/dist-packages/django/core/management/base.py", > line 294, in run_from_argv self.execute(*args, **cmd_options) File > "/usr/lib/python2.7/dist-packages/django/core/management/base.py", > line 345, in execute output = self.handle(*args, **options) File > "/usr/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", > line 86, in handle > executor.loader.check_consistent_history(connection) File > "/usr/lib/python2.7/dist-packages/django/db/migrations/loader.py", > line 292, in check_consistent_history connection.alias, > django.db.migrations.exceptions.InconsistentMigrationHistory: > Migration lava_scheduler_app.0001_initial is applied before its > dependency linaro_django_xmlrpc.0001_initial on database 'default'. > dpkg: error processing package lava-server (--configure): subprocess > installed post-installation script returned error exit status 1 > Processing triggers for python-support (1.0.15) ... Processing > triggers for libc-bin (2.24-8) ... Processing triggers for systemd > (232-14) ... Processing triggers for ca-certificates (20161130) ... > Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. > Running hooks in /etc/ca-certificates/update.d... done. Errors were > encountered while processing: lava-server list]) instead. > > I can easily provide more debug information from the chroot after the > failure, just tell me what you need (and how to acquire it). To fix the chroot, downgrade python-django, python-django-common and python-django-tables2 to jessie-backports versions. Then the upgrade to stretch will work. Or, as above, install these from jessie-backports first, then the upgrade proceeds. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp4qdugIJBFS.pgp
Description: OpenPGP digital signature
