Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Paul Gevers]

Hi all,

On 31-12-2019 22:50, Chris Lamb wrote:
> Hi László,
> 
>>   File "/<>/tests/admin_inlines/tests.py", line 1, in 
>> from selenium.common.exceptions import NoSuchElementException
>> ModuleNotFoundError: No module named 'selenium'
>>
>> Are you going to upload it fixed to Sid?
> 
> Thanks for uploading sqlite. This exception was already fixed in
> #947549…
> 
>> Happy New Year!
> 
> … you too. :)

I have given-back python-django, and it built now. Thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Chris Lamb]

Hi László,

>   File "/<>/tests/admin_inlines/tests.py", line 1, in 
> from selenium.common.exceptions import NoSuchElementException
> ModuleNotFoundError: No module named 'selenium'
> 
> Are you going to upload it fixed to Sid?

Thanks for uploading sqlite. This exception was already fixed in
#947549…

> Happy New Year!

… you too. :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[GCS]

On Sun, Dec 29, 2019 at 10:07 PM László Böszörményi (GCS)
 wrote:
> On Sun, Dec 29, 2019 at 5:57 PM Chris Lamb  wrote:
> > I don't fully understand the ramifications or risks of uploading the
> > current Fossil tree I'm afraid so I will have to leave that judgement
> > to you. Can you let me know your intention either way so that we don't
> > lose this down the cracks and delay Paul's work further? I would not
> > want to disable the test and remember to re-enable it again, after all.
>  OK, I did some testing and couldn't find any immediate problem. Going
> to upload the current Fossil tree soon, then follow what problem may
> arise in Debian or in upstream issues.
 The upload is done and built on all architectures. As I see, your
experimental upload now should be OK. At least the FTBFS reason is not
SQLite3 related but:
ERROR: admin_inlines.tests (unittest.loader._FailedTest)
[...]
  File "/<>/tests/admin_inlines/tests.py", line 1, in 
from selenium.common.exceptions import NoSuchElementException
ModuleNotFoundError: No module named 'selenium'

Are you going to upload it fixed to Sid?

Happy New Year!
Laszlo/GCS

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[GCS]

Hi Chris,

On Sun, Dec 29, 2019 at 5:57 PM Chris Lamb  wrote:
> I don't fully understand the ramifications or risks of uploading the
> current Fossil tree I'm afraid so I will have to leave that judgement
> to you. Can you let me know your intention either way so that we don't
> lose this down the cracks and delay Paul's work further? I would not
> want to disable the test and remember to re-enable it again, after all.
 OK, I did some testing and couldn't find any immediate problem. Going
to upload the current Fossil tree soon, then follow what problem may
arise in Debian or in upstream issues.

Regards,
Laszlo/GCS

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Chris Lamb]

Hi László,

> scheduled to 31st of December, this year but it was delayed with a
> whole month later

I don't fully understand the ramifications or risks of uploading the
current Fossil tree I'm afraid so I will have to leave that judgement
to you. Can you let me know your intention either way so that we don't
lose this down the cracks and delay Paul's work further? I would not
want to disable the test and remember to re-enable it again, after all.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[GCS]

Hi Paul, Chris,

On Sun, Dec 29, 2019 at 4:27 PM Chris Lamb  wrote:

> > @python-django maintainers what does this mean for the functionality of
> > python-django in bullseye? Is it "only" the test that fails and can that
> > thus be temporarily disabled?
>
> I would be amenable to disabling the test in python-django if a
> response or fix in sqlite3 is not forthcoming within a few days.
>
 It's a complex situation. SQLite3 upstream recently got fuzzing their
Fossil (source code management tool like Git) tree. Several vulnerabilities
are found - while upstream say these are only an issue if you allow
unauthenticated users enter free form SQL queries against your database.
That means only one possible application, the Chromium browser via WebSQL.
Indeed, a group of security  researchers found a way to exploit a remote
code execution in it, called Magellan 2.0 [1]. It was patched meanwhile and
at least Sid is not affected anymore.
While upstream is quick to fix these reported security problems, there were
introduced an other at least once. This is true for other fixes as well,
they broke something else then. Maybe this is the reason why 3.31.0 (the
next stable SQLite3 release) was first scheduled to 31st of December, this
year but it was delayed with a whole month [2] later. Of course I can
package the current Fossil tree, I'm not sure how it would work in many
scenarios. The upstream testing tools and cases are not open source thus I
can't test it. :-/
As I read, I should do the packaging nevertheless or Chris, may you solve
it with disabled tests?

Regards,
Laszlo/GCS
[1] https://blade.tencent.com/magellan2/index_en.html
[2] https://sqlite.org/draft/releaselog/3_31_0.html

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Chris Lamb]

Hi Paul,

> @python-django maintainers what does this mean for the functionality of
> python-django in bullseye? Is it "only" the test that fails and can that
> thus be temporarily disabled?

I would be amenable to disabling the test in python-django if a
response or fix in sqlite3 is not forthcoming within a few days.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Paul Gevers]

Hi,

On Sat, 26 Oct 2019 19:17:01 +0100 "Chris Lamb"  wrote:
> Hi László,
> 
> > But you mean plural packages? I knew only python-django. I meant
> > sure, it's a FTBFS in experimental where […]
> 
> I see what you mean now, thanks. I assumed it affected more packages
> and was more severe than just python-django from the description, but
> I admittedly had done no specific searching.
> 
> > In short, I don't get the importance of filing a FTBFS bug for a beta 
> > release in experimental.
> 
> Hah, well my defense I did not file this bug and indeed deliberately
> did not file any issue in Debian for this very reason when I first
> noticed it, prefering to file a bug upstream first (there have been
> similar short-term issues in other database backends in the past).
> 
> I would be perfectly happy with downgrading this to important and thus
> non-RC.
> 
> >  Yeah, you are British. :)
> 
> Don't quite follow that... :)

Can we please move this bug forward? python-django *in sid* has been
failing to build from source since the beginning of November. It's FTBFS
is hampering CVE fixes from reaching testing users and is hampering the
python 2 removal effort.

@python-django maintainers what does this mean for the functionality of
python-django in bullseye? Is it "only" the test that fails and can that
thus be temporarily disabled?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

On Sun, 3 Nov 2019 08:19:20 +0900 "ISHIKAWA,chiaki" 
 wrote:

> Hi,
>
> If I am not mistaken, Ubuntu version used on Mozilla's build server
> farms uses rather very old version of sqlite3.
>
>
> > [task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
> > [task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
> > [task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu
>
>
> Maybe I should downgrade to this and then upgrade a bit until local 
test breaks.

>
> From: https://launchpad.net/ubuntu/xenial/+source/sqlite3
>
> Updates
>
> Package versions including new features after the distribution
> release has been made. Updates are usually turned on by default
> after a fresh install.
>
> * sqlite3 3.11.0-1ubuntu1.2
> 
> (main)
>

I downgraded the sqlite to 3.11.0 used in the first release of ubutno 
Xenial Xerus as noted above.


Unfortunately, the indexedDB errors I saw with mozilla Thunderbird test 
suite did not disappear.


This means that something else that changed between late August and 
middle October (quite likely some other packages) may be to blame.


I will continue investigating, but I *think* sqlite3 was not to blame 
for Thunderbird test failures.


Sorry for the noise.

TIA

Chiaki

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Hi,

If I am not mistaken, Ubuntu version used on Mozilla's build server 
farms uses rather very old version of sqlite3.


  

[task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
[task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
[task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu



Maybe I should downgrade to this and then upgrade a bit until local test breaks.

From: https://launchpad.net/ubuntu/xenial/+source/sqlite3

Updates

   Package versions including new features after the distribution
   release has been made. Updates are usually turned on by default
   after a fresh install.

 * sqlite3 3.11.0-1ubuntu1.2
   
   (main)

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Dear Laszló,

Thank you for your e-mail.

(Sorry my local system does not seem to have the correct font for the 
character in your name, and so I am not sure if I am writing the name 
correctly.

I hope it will show correctly on your end.)

My comments inline:

On 2019/11/01 23:44, László Böszörményi (GCS) wrote:

Hi Chiaki,

On Thu, Oct 31, 2019 at 9:09 PM ISHIKAWA,chiaki  wrote:

I vouch that there seems to be a serious issue in libsqlite3 3.30.1-1.

  It's not that fatal like it may seem so.

I wish that is  the case.

I came here because it seems that I have an issue with sqlite3 on my
linux installation.
The problem manifested as database operation failures during thunderbird
mail client regression testing (called mach xcpshell-tests|)

  Is there a documented way to get and run it locally?


There is a series of documents.
However, it is such a long winding path, it may take a few days to set 
up and  run correctly.

I can't really suggest that you take the steps outlined below casually.

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Thunderbird_build

My summary is as follows.

First you have to download the source for C-C (comm-central) AND M-C 
(mozilla-central.)

M-C should be installed somewhere with mozilla directory name.
C-C needs to be installed as comm immediately below mozilla directory.

Then you have to configure the development environment.
Setting environment variables and configuration file and set an 
environment variable, MOZCONFIG,

that points to the config file.
You have to specify the MOZ_OBJDIR that stores the generated binary: 
this object directory MUST be

outside the source tree.

Before building,
you have to download a series of debian package header files and 
libraries (i.e., development library packages) that are used by

the thunderbird build process.
There are a lot actually under Debian that we need to install on top of 
regular installation.


*THEN*
We run the compilation process using so-called |../mach build| command 
in the C-C topmost directory (comm) immediately below M-C (mozill)a 
directory.


This command will likely suggest that we need to install clang c++ 
compiler and rust compiler with many packages.

It prints out the commands how to perform these actions. So I follow it.

Once the compilation is successful, we can finally run
xpcshell test by

cd $MOZOBJ || exit 1

...    mozilla/mach --log-no-times xpcshell-test

where mach command is in the mozilla source directory (M-C).

Build takes about 1 hour on my Ryzen1700 with 16GB memory.
(Actually, Debian GNU/Linux amd64 image that runs inside VirtualBox that 
runs on top Windows10 Pro 64 bit)


If you really are interested, I can help.

There are all sorts of minor issues that pop up from time to time when 
we use open source tools and libraries.
Usually error messages are clear, but sometimes python and other script 
language errors pop up and they are difficult to analyze.




I looks someone on Ubuntu did not see it this month and mozilla's
compilation and testing farm machines do not seem to see it. They run
CentOs if I am not mistaken.

  Which version of CentOS? Its latest release, versioned 8 has SQLite3
3.26.0 if I'm not mistaken.


Oh, I was wrong. The compilation/test farm machines have transitioned to 
Ubuntu sometime before.
I did not know that. Maybe we can know what sqlite3 version is working 
there.

I see the following version info of OS. It seems a very old OS package.

[task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
[task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
[task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu
[task 2019-10-31T22:44:44.290Z] ++ ID_LIKE=debian
[task 2019-10-31T22:44:44.290Z] ++ PRETTY_NAME='Ubuntu 16.04.5 LTS'
[task 2019-10-31T22:44:44.291Z] ++ VERSION_ID=16.04

from 
https://taskcluster-artifacts.net/OtJtVGBiQkax0LeOVJAcbw/0/public/logs/live_backing.log

This is from a build/test job submission result:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central=e1c9f00a40034361a9a3b6c4abdf0807e22c5d7e

Mozilla has a rather nice build/test farm setup.




https://bugzilla.mozilla.org/show_bug.cgi?id=1589779

So I thought maybe the current installation of libsqlite3 on my linux PC
was to blame.

  Might be, but SQLite3 3.30.1 should be safe.

I am still trying to find out what changed between latest August and 
beginning of October.


It can be

- my PC environment changes (including package updates), or
- even testing environment change (but unlikely).

Since someone under Ubuntu told me the test works there without an 
issue, I think

local package version issue is more like it.


Well, it looks that is the case if I read the exchanges here correctly.
My libsqlite3 seems to be affected: the version is 3.30.1-1
(The problem was not observed in August. I am not sure if the upgrade of
libsqlite3 happened during then and now.)

What do people suggest that best course of action under the circumstances?

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[GCS]

Hi Chiaki,

On Thu, Oct 31, 2019 at 9:09 PM ISHIKAWA,chiaki  wrote:
> I vouch that there seems to be a serious issue in libsqlite3 3.30.1-1.
 It's not that fatal like it may seem so.

> I came here because it seems that I have an issue with sqlite3 on my
> linux installation.
> The problem manifested as database operation failures during thunderbird
> mail client regression testing (called mach xcpshell-tests|)
 Is there a documented way to get and run it locally?

> I looks someone on Ubuntu did not see it this month and mozilla's
> compilation and testing farm machines do not seem to see it. They run
> CentOs if I am not mistaken.
 Which version of CentOS? Its latest release, versioned 8 has SQLite3
3.26.0 if I'm not mistaken.

> https://bugzilla.mozilla.org/show_bug.cgi?id=1589779
>
> So I thought maybe the current installation of libsqlite3 on my linux PC
> was to blame.
 Might be, but SQLite3 3.30.1 should be safe.

> Well, it looks that is the case if I read the exchanges here correctly.
> My libsqlite3 seems to be affected: the version is 3.30.1-1
> (The problem was not observed in August. I am not sure if the upgrade of
> libsqlite3 happened during then and now.)
>
> What do people suggest that best course of action under the circumstances?
>
> Downgrade (to which version and how) or install newer libsqlite3 (where)?
 All uploaded SQLite3 Debian packages should be archived[1]. Try
downgrading it to 3.29.0-2 first and see if it helps.

> All I can say is that the same tests that deal with database that worked
> for years suddenly broke in the last several weeks. So my bug report
> would not be that useful :-(
 May you have a date when you first experienced it? As sqlite3 3.30.0
is in the Debian archives since the fifth of October, this may narrow
down the issue a bit.

Regards,
Laszlo/GCS
[1] http://snapshot.debian.org/package/sqlite3/

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Hi,

I vouch that there seems to be a serious issue in libsqlite3 3.30.1-1.

I came here because it seems that I have an issue with sqlite3 on my 
linux installation.
The problem manifested as database operation failures during thunderbird 
mail client regression testing (called mach xcpshell-tests|)


I looks someone on Ubuntu did not see it this month and mozilla's 
compilation and testing farm machines do not seem to see it. They run 
CentOs if I am not mistaken.


https://bugzilla.mozilla.org/show_bug.cgi?id=1589779

So I thought maybe the current installation of libsqlite3 on my linux PC 
was to blame.


Well, it looks that is the case if I read the exchanges here correctly.
My libsqlite3 seems to be affected: the version is 3.30.1-1
(The problem was not observed in August. I am not sure if the upgrade of 
libsqlite3 happened during then and now.)


What do people suggest that best course of action under the circumstances?

Downgrade (to which version and how) or install newer libsqlite3 (where)?

Your guidance is appreciated.

TIA

Chiaki

PS: if necessary, I can file a separate bug report to escalate this 
issue, but it would be weeks until I can come up with a very simplified 
test case since the problems occur inside the complex test harness: I 
don't understand the innards very well.


All I can say is that the same tests that deal with database that worked 
for years suddenly broke in the last several weeks. So my bug report 
would not be that useful :-(

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Chris Lamb]

Hi László,

> But you mean plural packages? I knew only python-django. I meant
> sure, it's a FTBFS in experimental where […]

I see what you mean now, thanks. I assumed it affected more packages
and was more severe than just python-django from the description, but
I admittedly had done no specific searching.

> In short, I don't get the importance of filing a FTBFS bug for a beta 
> release in experimental.

Hah, well my defense I did not file this bug and indeed deliberately
did not file any issue in Debian for this very reason when I first
noticed it, prefering to file a bug upstream first (there have been
similar short-term issues in other database backends in the past).

I would be perfectly happy with downgrading this to important and thus
non-RC.

>  Yeah, you are British. :)

Don't quite follow that... :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Andreas Beckmann]

On 26/10/2019 17.13, László Böszörményi (GCS) wrote:
> In short, I don't get the importance of filing a FTBFS bug for a beta
> release in experimental.

I'm filing bugs for artefacts discovered by QA. I don't know if it is a
beta, RC, or whatever release. I only noticed "something is not
working". Having a bug number lets me put it in the "someone will take
care of it eventually" category.


Andreas

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[GCS]

Hi Chris,

On Sat, Oct 26, 2019 at 2:48 PM Chris Lamb  wrote:

> Not quite sure what you mean by bad. It's "bad" in that it's causing
> an FTBFS in other packages, but I don't think that's quite what you
> meant here. :)
>
 Yeah, you are British. :) But you mean plural packages? I knew only
python-django. I meant sure, it's a FTBFS in experimental where people
expect failures and maintainers follow it more closely. Doesn't upload the
package to Sid before all issues are solved.
What are the surroundings? Do you need a clean compile soon because you are
testing some important bugfix / alternative compilation method, an upstream
release which adds a long awaited feature (users are expecting that soon),
etc?
It's a beta of Django and even a RC release might be far away. I've doubts
SQLite3 upstream will do a minor updated release. I think the new SQLite3
stable upstream release can be a month away. Should I upload a Fossil
snapshot of that to experimental immediately?
In short, I don't get the importance of filing a FTBFS bug for a beta
release in experimental.

Regards,
Laszlo/GCS

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Chris Lamb]

Hi László,

> > https://code.djangoproject.com/ticket/30879
> > 
> >  It appears to be an issue in sqlite 3.30.1.
>
>  Indeed, the bug is in SQLite3 but the mentioned fix and its successor 
> don't fix this issue. The current HEAD yes, but that may introduce 
> other problems. I'm interested how bad the current situation is?

Not quite sure what you mean by bad. It's "bad" in that it's causing
an FTBFS in other packages, but I don't think that's quite what you
meant here. :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[GCS]

On Sat, Oct 26, 2019 at 11:33 AM Chris Lamb  wrote:

> > python-django/experimental FTBFS:
>
> Indeed. I noticed this after uploading and reported it upstream here:
>
>   https://code.djangoproject.com/ticket/30879
>
> It appears to be an issue in sqlite 3.30.1.
>
 Indeed, the bug is in SQLite3 but the mentioned fix and its successor
don't fix this issue. The current HEAD yes, but that may introduce other
problems. I'm interested how bad the current situation is? My computer is a
bit slow to bisect the fixing commit(s). But I may upload the updated
sqlite3 package to experimental if that helps for now.

Regards,
Laszlo/GCS

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Chris Lamb]

reassign 943509 sqlite3 3.30.1-1
affects 943509 python-django
thanks

Hi Andreas,

> python-django/experimental FTBFS:

Indeed. I noticed this after uploading and reported it upstream here:

  https://code.djangoproject.com/ticket/30879

It appears to be an issue in sqlite 3.30.1.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Andreas Beckmann]

Source: python-django
Version: 2:3.0~beta1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

python-django/experimental FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=python-django=all=2%3A3.0%7Ebeta1-1=1571079369=0


==
FAIL: test_explicit_ForeignKey 
(nested_foreign_keys.tests.DeeplyNestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 176, in 
test_explicit_ForeignKey

self.assertEqual(Package.objects.exclude(screening__movie__director=self.director).count(),
 1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_inheritance (nested_foreign_keys.tests.DeeplyNestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 153, in 
test_inheritance

self.assertEqual(Event.objects.exclude(screening__movie__director=self.director).count(),
 1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_explicit_ForeignKey 
(nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 100, in 
test_explicit_ForeignKey

self.assertEqual(Package.objects.exclude(screening__movie=self.movie).count(), 
1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_explicit_ForeignKey_NullFK 
(nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 121, in 
test_explicit_ForeignKey_NullFK

self.assertEqual(PackageNullFK.objects.exclude(screening__movie=self.movie).count(),
 2)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 1 != 2

==
FAIL: test_inheritance (nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 53, in 
test_inheritance

self.assertEqual(Event.objects.exclude(screening__movie=self.movie).count(), 1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_inheritance_null_FK 
(nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File