britney explodes when there is a version collision between overlay PPA and archive

For the last day or so britney has been unable to run on xenial
tickets, giving this traceback:

Traceback (most recent call last):
  File "/var/lib/britney/britney.py", line 3221, in <module>
    Britney().main()
  File "/var/lib/britney/britney.py", line 331, in __init__
    self.binaries['testing'][arch] =
self.read_binaries(self.options.testing, "testing", arch)
  File "/var/lib/britney/britney.py", line 1100, in read_binaries
    self.sources[distribution])
  File "/var/lib/britney/britney.py", line 978, in _read_packages_file
    self.merge_pkg_entries(pkg, arch, all_binaries[pkg_id], dpkg)
  File "/var/lib/britney/britney.py", line 404, in merge_pkg_entries
    raise ValueError("Invalid data set")
ValueError: Invalid data set

Upon inspection, it was discovered that britney was getting confused
by two different indicator-power packages with the same version
number, one in xenial-proposed and one in xenial overlay:

https://launchpad.net/ubuntu/+source/indicator-power/12.10.6+16.04.20160708-0ubuntu1
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/6711772/+listing-archive-extra

The xenial-proposed one is an SRU from this ticket:

https://requests.ci-train.ubuntu.com/#/ticket/1649#audit_log

The overlay one is part of a trio landing from this ticket:

https://requests.ci-train.ubuntu.com/#/ticket/1648#audit_log

A simple coincidence that both tickets were built on the same day the
same number of times (once) and thus had the same version number.

I've deleted the package from xenial overlay in order to unblock
britney, if it is desired to restore that package to xenial overlay it
will need to be reuploaded with a new version number, which will
happen automatically next time there is a trio landing anyway (or if
it's more urgent the version number can be manually bumped and
reuploaded).

Bileto already has code to prevent publishing two tickets with version collisions when they target the same destination, as you might have seen the 'Needs rebuild due to burned version number' status in the wild. In this case that wasn't triggered because the SRU ticket did not check the overlay for conflicts.

I suppose I should alter the version checker thing to always consider the overlay even if that is not the destination of the ticket.