On Wednesday 31 May 2017 03:00 AM, Brian May wrote:
> Raphael Hertzog writes:
>
>> Is that actually true? linaro_django_xmlrpc seems to be listed in
>> INSTALLED_APPS, no?
>>
>> Do you have any idea why it would give this error?
>
> I note that linaro_django_xmlrpc is
Raphael Hertzog writes:
> Is that actually true? linaro_django_xmlrpc seems to be listed in
> INSTALLED_APPS, no?
>
> Do you have any idea why it would give this error?
I note that linaro_django_xmlrpc is towards the end of
INSTALLED_APPS. Maybe it did not get loaded?
Maybe
On Tuesday 30 May 2017 08:39 PM, Raphael Hertzog wrote:
> On Tue, 30 May 2017, Senthil Kumaran S wrote:
>> I tested the new version ie., test2 and got a traceback as shown here -
>> File "/usr/lib/python2.7/dist-packages/django/db/migrations/state.py",
>> line 249, in __init__
>> raise
Hi,
On Tue, 30 May 2017, Senthil Kumaran S wrote:
> I tested the new version ie., test2 and got a traceback as shown here -
> File "/usr/lib/python2.7/dist-packages/django/db/migrations/state.py",
> line 249, in __init__
> raise ValueError("\n".join(error.msg for error in errors))
>
On Tuesday 30 May 2017 06:09 PM, Senthil Kumaran S wrote:
> I tested the new version ie., test2 and got a traceback as shown here -
> http://paste.debian.net/952939/
When combined with the attached patch for lava-server the migration
works fine as seen here - http://paste.debian.net/952953/
On Tuesday 30 May 2017 05:15 PM, Raphael Hertzog wrote:
> Thanks, can you try again with another test version ?
> $ dget
> https://people.debian.org/~hertzog/packages/python-django_1.10.7-2~test2_amd64.changes
> (test2 now, no longer test1)
I tested the new version ie., test2 and got a
On Tue, 30 May 2017, Senthil Kumaran S wrote:
> I tested the patch with lava-server, which ended up with a traceback as
> seen here - http://paste.debian.net/952276/
Thanks, can you try again with another test version ?
$ dget
On Monday 29 May 2017 08:54 PM, Raphael Hertzog wrote:
> On Mon, 29 May 2017, Raphael Hertzog wrote:
>> Updated patches attached, I missed to update some tests to account
>> for the move of the detect_soft_applied() method.
>
> Third set of patches, this time the package builds fine at least.
>
On Monday 29 May 2017 08:54 PM, Raphael Hertzog wrote:
> On Mon, 29 May 2017, Raphael Hertzog wrote:
>> Updated patches attached, I missed to update some tests to account
>> for the move of the detect_soft_applied() method.
>
> Third set of patches, this time the package builds fine at least.
>
On Mon, 29 May 2017, Raphael Hertzog wrote:
> Updated patches attached, I missed to update some tests to account
> for the move of the detect_soft_applied() method.
Third set of patches, this time the package builds fine at least.
Which means you can just test this package and let me know if it
On Mon, 29 May 2017, Raphael Hertzog wrote:
> Option 4. Fix Django 1.10 with the attached patches.
Updated patches attached, I missed to update some tests to account
for the move of the detect_soft_applied() method.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS:
On Mon, 29 May 2017, Brian May wrote:
> Otherwise, I think we have three options. I recommend reading the Django
> ticket in full before deciding.
[…]
> 1. Apply work around from
> https://code.djangoproject.com/ticket/28250#comment:1 by manually
[…]
> 2. Remove migration from postinst, and give
On 2017-05-26 19:05, Neil Williams wrote:
> No. This is django making the wrong decision about problems it has
> previously supported when trying to include bug fixes for other
> problems. It is a regression in django 1.10
Feel free to argue this point in
control: forwarded -1 https://code.djangoproject.com/ticket/28250#ticket
Brian May writes:
> B. Create a Django bug report pointing to our test case. They may or may
> not accept it as a bug in Django, however it would be good to get their
> feedback.
Done:
Some misconceptions resolved:
* This bug does not cause any data to be deleted.
* This bug does not cause any data to be currupted.
* This bug does not cause any data to be lost.
* This bug only affects one application. Out of many others that use Django.
The damage this bug does cause:
* If
Neil Williams writes:
> Again, I also spotted this and thought it was the source. However,
> changing this causes the migration to fail with 1.10 as there are
> objects in this model which must be applied before
> lava_scheduler_app/0001_initial will complete. e.g. the
On Fri, 26 May 2017 10:16:41 +0100
Neil Williams wrote:
> On Fri, 26 May 2017 10:05:58 +0100
> Neil Williams wrote:
>
> > On Fri, 26 May 2017 18:56:04 +1000
> > Brian May wrote:
> >
> > > Neil Williams writes:
On Fri, 26 May 2017 18:56:04 +1000
Brian May wrote:
> Neil Williams writes:
>
> > django.db.migrations.exceptions.InconsistentMigrationHistory:
> > Migration lava_scheduler_app.0001_initial is applied before its
> > dependency
Neil Williams writes:
> django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
> lava_scheduler_app.0001_initial is applied before its dependency
> linaro_django_xmlrpc.0001_initial on database 'default'.
Ok, I see what is going on now. Untested theory at
On Fri, 26 May 2017 18:20:07 +1000
Brian May wrote:
> Neil Williams writes:
>
> > Applying linaro_django_xmlrpc.0001_initial... FAKED
>
> I am speculating this line might be very relevant. Taken from the
> Django 1.8 migration.
>
> Looks like this
Neil Williams writes:
> Applying linaro_django_xmlrpc.0001_initial... FAKED
I am speculating this line might be very relevant. Taken from the Django
1.8 migration.
Looks like this never had a migration before, so now needs to be
faked. I wonder if this is what is
On Fri, 26 May 2017 18:05:08 +1000
Brian May wrote:
> Neil Williams writes:
>
> > Upgrading directly to Stretch:
>
> Just to clarify: Was this upgrading the entire system to stretch, or
> just the relevant packages?
Starting point was 8.8 jessie,
Neil Williams writes:
> Upgrading directly to Stretch:
Just to clarify: Was this upgrading the entire system to stretch, or
just the relevant packages?
--
Brian May
23 matches
Mail list logo