ubuntu-support-status throws exeption No date tag found (regression)

[Morty]

Test Case
---------
1) Run ubuntu-support-status and observe a crash
2) Install python3-apt from the -proposed repository
3) Run ubuntu-support-status and see your status

Description: Ubuntu 14.04.3 LTS
Release: 14.04
update-manager-core: 1:0.196.14

Since the last update ubuntu-support-status throws

Traceback (most recent call last):
  File "/usr/bin/ubuntu-support-status", line 133, in <module>
    pkg.name, support_tag)
  File "/usr/bin/ubuntu-support-status", line 49, in get_maintenance_status
    raise Exception("No date tag found")
Exception: No date tag found

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brian Murray (brian-murray)]

Could you try running the attached version of ubuntu-support-status in a terminal? You should be able to just put in it /tmp and run it via ./ubuntu-support-status. Thanks!

[Andrei Borzenkov (arvidjaar-s)]

bor@bor-Latitude-E5450:~/build/grub$ chmod +x /tmp/ubuntu-support-status
bor@bor-Latitude-E5450:~/build/grub$ /tmp/ubuntu-support-status
Traceback (most recent call last):
  File "/tmp/ubuntu-support-status", line 13, in <module>
    from UpdateManager.Core.utils import twrap
ImportError: No module named UpdateManager.Core.utils
bor@bor-Latitude-E5450:~/build/grub$

Some package missing?

[Morty (morty)]

I can confirm Andrei.

[Brian Murray (brian-murray)]

Ah, let's try setting the PYTHONPATH then e.g.:

[ 10:35AM 10113 ] [ bdmurray@impulse:/tmp ]
 $ ./ubuntu-support-status
Traceback (most recent call last):
  File "./ubuntu-support-status", line 13, in <module>
    from UpdateManager.Core.utils import twrap
ImportError: No module named UpdateManager.Core.utils
[ 10:35AM 10114 ] [ bdmurray@impulse:/tmp ]
 $ PYTHONPATH=$PYTHONPATH:/usr/lib/python3/dist-packages/ ./ubuntu-support-status

[Andrei Borzenkov (arvidjaar-s)]

bor@bor-Latitude-E5450:~/build/grub$ PYTHONPATH=$PYTHONPATH:/usr/lib/python3/dist-packages/ /tmp/ubuntu-support-status
Traceback (most recent call last):
  File "/tmp/ubuntu-support-status", line 120, in <module>
    (still_supported, support_str) = get_maintenance_status(cache, pkg.name, support_tag)
  File "/tmp/ubuntu-support-status", line 41, in get_maintenance_status
    raise Exception("No date tag found for %s" % releasef)
Exception: No date tag found for /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_trusty-updates_Release
bor@bor-Latitude-E5450:~/build/grub$

[Andrei Borzenkov (arvidjaar-s)]

bor@bor-Latitude-E5450:~/build/grub$ LC_ALL=C ll /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_trusty-updates_Release
ls: cannot access /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_trusty-updates_Release: No such file or directory
bor@bor-Latitude-E5450:~/build/grub$ LC_ALL=C ll /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_trusty-updates_InRelease
-rw-r--r-- 1 root root 64439 Oct 13 06:28 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_trusty-updates_InRelease
bor@bor-Latitude-E5450:~/build/grub$

System came preinstalled on this Dell if it matters. I did update it and installed quite a bit since then though.

[Morty (morty)]

Same here:

PYTHONPATH=$PYTHONPATH:/usr/lib/python3/dist-packages/ ./ubuntu-support-status
Traceback (most recent call last):
  File "./ubuntu-support-status", line 120, in <module>
    (still_supported, support_str) = get_maintenance_status(cache, pkg.name, support_tag)
  File "./ubuntu-support-status", line 41, in get_maintenance_status
    raise Exception("No date tag found for %s" % releasef)
Exception: No date tag found for /var/lib/apt/lists/ftp.fau.de_ubuntu_dists_trusty-updates_Release

[Dimitri Papadopoulos (dimitri-papadopoulos)]

$ PYTHONPATH=$PYTHONPATH:/usr/lib/python3/dist-packages/ ~/ubuntu-support-status
Traceback (most recent call last):
  File "/home/dp165978/ubuntu-support-status", line 120, in <module>
    (still_supported, support_str) = get_maintenance_status(cache, pkg.name, support_tag)
  File "/home/dp165978/ubuntu-support-status", line 41, in get_maintenance_status
    raise Exception("No date tag found for %s" % releasef)
Exception: No date tag found for None
$

[Steve Beattie (sbeattie)]

This is also occurring on wily, see bug 1506510.

[Steve Beattie (sbeattie)]

Here's what I see on wily when making the following change:

--- /usr/bin/ubuntu-support-status 2015-10-08 22:07:36.000000000 -0700
+++ ./ubuntu-support-status 2015-10-23 14:49:44.092719697 -0700
@@ -48,7 +48,7 @@
     # check the release date and show support information
     # based on this
     if not time_t:
- raise Exception("No date tag found")
+ raise Exception("No date tag found for %s on package %s" % (releasef, pkgname))
     release_date = datetime.datetime.fromtimestamp(time_t)
     now = datetime.datetime.now()

$ python3 ./ubuntu-support-status
Traceback (most recent call last):
  File "./ubuntu-support-status", line 135, in <module>
    pkg.name, support_tag)
  File "./ubuntu-support-status", line 51, in get_maintenance_status
    raise Exception("No date tag found for %s on package %s" % (releasef, pkgname))
Exception: No date tag found for /var/lib/apt/lists/ubuntu-mirror.nxnw.org_ubuntu_dists_wily_Release on package abi-compliance-checker

There is no /var/lib/apt/lists/ubuntu-mirror.nxnw.org_ubuntu_dists_wily_Release available, the specific file is /var/lib/apt/lists/ubuntu-mirror.nxnw.org_ubuntu_dists_wily_InRelease (note the difference between Release and InRelease).

Looking at https://wiki.debian.org/RepositoryFormat both Release and InRelease files are legitimate entries (the former is externally signed by gpg, the latter inline signed), so it looks like get_release_filename_for_pkg() from python-apt should be verifying that the release file exists before returning it.

[Steve Beattie (sbeattie)]

Note that on a trusty host I have where ubuntu-support-status doesn't throw a traceback, the following files exist:

-rw-r--r-- 1 root root 64441 Oct 22 23:53 /var/lib/apt/lists/ubuntu-mirror.nxnw.org_ubuntu_dists_trusty-security_InRelease
-rw-r--r-- 1 root root 63459 Oct 1 23:28 /var/lib/apt/lists/ubuntu-mirror.nxnw.org_ubuntu_dists_trusty-security_Release

The latter being outdated with respect to the former. apt should probably be cleaning these out.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Julian Andres Klode (juliank)]

Not a bug in python-apt, but in the update-manager, so I'm marking the python-apt task as invalid.

[Steve Beattie (sbeattie)]

Julian, sorry, but python-apt in get_release_filename_for_pkg() hardcodes the string '_Release' to the path returned by the function regardless of whether apt has downloaded a _Release or _InRelease file. Here's a prototype patch I worked up to address that:

diff -Nru python-apt-1.0.1build1/apt/utils.py python-apt-1.0.1ubuntu0.1~test2/apt/utils.py
--- python-apt-1.0.1build1/apt/utils.py 2015-10-01 13:12:19.000000000 -0700
+++ python-apt-1.0.1ubuntu0.1~test2/apt/utils.py 2015-10-23 16:06:36.000000000 -0700
@@ -82,7 +82,9 @@
                     indexfile.describe == m.describe and
                     indexfile.is_trusted):
                 dirname = apt_pkg.config.find_dir("Dir::State::lists")
- name = (apt_pkg.uri_to_filename(metaindex.uri) +
- "dists_%s_Release" % metaindex.dist)
- return dirname + name
+ for relfile in ['Release', 'InRelease']:
+ name = (apt_pkg.uri_to_filename(metaindex.uri) +
+ "dists_%s_%s" % (metaindex.dist, relfile))
+ if os.path.exists(dirname + name):
+ return dirname + name
     return None

[Steve Beattie (sbeattie)]

Here it is in patch form. Note that it doesn't entirely address the issue as passing the _InRelease file to python-apt's get_release_date_from_release_file(path) function ends up handing the file to pkg_apt.TagFile() which doesn't recognize the inline gpg signed file as a RFC 2822 tag formatted file; presumably something needs to verify and remove the gpg signature before handing it off to pkg_apt.TagFile(). I'm not familiar as all with the pkg_apt (aka libpkg-apt) APIs, and they are large enough for me not to see an obvious method for doing that.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "python-apt-fix_hardcoded_release_path.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Julian Andres Klode (juliank)]

OK, that makes sense. Sorry, I did not see that from the bug report and did not remember apt.utils existing.

To ignore the signature, we need to open the InRelease file using apt_pkg.open_maybe_clear_signed_file() and pass the returned file descriptor to the TagFile, AFAICT.

[MegaBrutal (qbu6to)]

Same here:

$ ubuntu-support-status
Traceback (most recent call last):
  File "/usr/bin/ubuntu-support-status", line 135, in <module>
    pkg.name, support_tag)
  File "/usr/bin/ubuntu-support-status", line 51, in get_maintenance_status
    raise Exception("No date tag found")
Exception: No date tag found

Line numbers are different, but I think it's the same error, because the same exception is raised, and those line numbers don't differ too much... I guess I have a different version of the script which still has the reported bug.

[Brian Murray (brian-murray)]

I've worked on a patch for this but it doesn't look like open_maybe_clear_signed_file() exists in Trusty.

[Brian Murray (brian-murray)]

Thanks for looking into this Steve. This is a complete patch which resolves the issue for me on Xenial.

[Steve Beattie (sbeattie)]

Brian, this patch both works for and looks good to me (not sure what upstream thinks of it). Thanks.

[Beverley (bev-4)]

How do I apply this patch?

[Julian Andres Klode (juliank)]

There's no real point doing that:

+ if path.endswith('InRelease'):
+ data = os.fdopen(apt_pkg.open_maybe_clear_signed_file(path))
+ else:
+ data = open(path)

Just use the open_maybe_clear_signed_file path all the time, that's why it's "maybe" after all.

+ for relfile in ['Release', 'InRelease']:

I'd prefer that the other way around.

Would be nice if you could send a git commit without the changelog entry upstream, then we can apply it to the git repository. Best with a commit message like this:

apt/utils.py: changes to parse InRelease files [or better something starting with a verb]

<LONG DESCRIPTION>

LP: #1503979

[Julian Andres Klode (juliank)]

This bug has been fixed upstream in commit d18826071a2a7fda9ff52fba215494074a528651, you can see the commit at:

https://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=d18826071a2a7fda9ff52fba215494074a528651

The changelog message is:

commit d18826071a2a7fda9ff52fba215494074a528651
Author: Julian Andres Klode <email address hidden>
Date: Thu Nov 26 17:26:21 2015 +0100

    apt.utils: Support parsing InRelease files

    Do not only look at Release files, but look at InRelease files
    as well. Change the code to open Release and InRelease files
    with apt_pkg.open_maybe_clear_signed_file() which will ignore
    the signature if it exists.

    LP: #1503979

Notes:
    Original patch by Brian Murray <email address hidden>

[Julian Andres Klode (juliank)]

This is fixed in upstream release 1.1.0~beta1, which is a stable release accompanying the APT 1.1 release.

It's a beta because it still uses some deprecated code...

[Ｖ字龍(Vdragon) (vdragon)]

Hi, not really relate to the bug but my apport window listed an invalid duplicate bug #1509643, please checkout the attatched screenshot:

[Andrei Borzenkov (arvidjaar-s)]

Why this bug suddenly became Invalid?

[Julian Andres Klode (juliank)]

Only the Update manager task became invalid, the python-apt task is still confirmed.

This is fixed in proposed already with python-apt 1.1 beta 1.

[Brian Murray (brian-murray)]

Julian - given that open_maybe_clear_signed_file() doesn't exist in Trusty how could I go about fixing this for that release? Would it be easy to add that function?

[Julian Andres Klode (juliank)]

According to git, the function was first shipped in APT 0.9.8, so you should be able to just apply

http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=d92026e96db4a4d03cec9f135b5407804892c55f

to trusty's python-apt , and maybe:

http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=6fb8772391b29974985c7194bb7a4cdbff86b12d

[Brian Murray (brian-murray)]

I've upload the fix for this to the SRU queue for Trusty and Wily. The Trusty changes also included a fix for a test that is currently failing.

[Steve Langasek (vorlon)]

Hello Morty, or anyone else affected,

Accepted python-apt into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python-apt/0.9.3.5ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Steve Langasek (vorlon)]

Hello Morty, or anyone else affected,

Accepted python-apt into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python-apt/1.0.1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Mathew Hodson (mathew-hodson)]

Fixed with python-apt (0.9.3.5ubuntu2) on Trusty.

$ ubuntu-support-status
Support status summary of 'mathew-VGN-FW455D':

You have 220 packages (10.0%) supported until February 2015 (9m)
You have 1879 packages (85.2%) supported until May 2019 (5y)
You have 12 packages (0.5%) supported until September 2016 (9m)
You have 36 packages (1.6%) supported until May 2017 (3y)

You have 15 packages (0.7%) that can not/no longer be downloaded
You have 43 packages (2.0%) that are unsupported

Run with --show-unsupported, --show-supported or --show-all to see more details

$ apt list python-apt
Listing... Done
python-apt/trusty-proposed,now 0.9.3.5ubuntu2 amd64 [installed,automatic]

[Steve Beattie (sbeattie)]

I reproduced the issue with python-apt 1.0.1ubuntu0.1 in Wily, and can confirm that the proposed version 1.0.1ubuntu0.1 solves the issue.

$ ubuntu-support-status
Support status summary of 'wily-amd64':

You have 2237 packages (85.3%) supported until July 2016 (9m)
You have 4 packages (0.2%) supported until August 2016 (9m)

You have 107 packages (4.1%) that can not/no-longer be downloaded
You have 276 packages (10.5%) that are unsupported

Run with --show-unsupported, --show-supported or --show-all to see more details

$ apt list python3-apt -a
Listing... Done
python3-apt/wily-proposed,now 1.0.1ubuntu0.1 amd64 [installed]
python3-apt/wily 1.0.1build1 amd64

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-apt - 1.1.0~beta1

---------------
python-apt (1.1.0~beta1) unstable; urgency=medium

  * Upload to unstable

  [ Michael Vogt ]
  * Do not show pulse progress when the output is not a tty
  * Fix build-dependencies parsing from debian/control
  * Print the failed function name in PyPkgManager::res()

  [ Julian Andres Klode ]
  * test_paths.py: Catch the IndexRecords warning
  * Release 1.0.1
  * changelog: Fix up the uploader name and close Barry's bug
  * doc: tutorials: contribution: Rewrite for git and other changes
    (Closes: #802084)
  * Build with cleaner headers
  * Use pkgCache::Version::No instead of pkgCache::Version::None
  * apt.utils: Support parsing InRelease files (LP: #1503979)
    Thanks to Brian Murray <email address hidden> for the initial patch.
  * apt.utils: Open the release files using a 'with' statement

  [ Jakub Wilk ]
  * apt/debfile.py: Fix typo
  * apt/debfile.py: Fix typo

  [ Martin Pitt ]
  * ./data/templates/Ubuntu.info.in: Add Xenial template.
  * doc/source/examples/apt-cdrom.py: Fix PEP-8 errors.

 -- Julian Andres Klode <email address hidden> Thu, 26 Nov 2015 17:32:28 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-apt - 1.0.1ubuntu0.1

---------------
python-apt (1.0.1ubuntu0.1) wily; urgency=medium

  * Do not only look at Release files, but look at InRelease files as well.
    Change the code to open Release and InRelease files with
    apt_pkg.open_maybe_clear_signed_file() which will ignore the signature if
    it exists. (LP: #1503979)

 -- Brian Murray <email address hidden> Wed, 02 Dec 2015 10:21:45 -0800

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for python-apt has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-apt - 0.9.3.5ubuntu2

---------------
python-apt (0.9.3.5ubuntu2) trusty-proposed; urgency=medium

  * Do not only look at Release files, but look at InRelease files as well.
    Change the code to open Release and InRelease files with
    apt_pkg.open_maybe_clear_signed_file() which will ignore the signature if
    it exists. (LP: #1503979)
  * tests/test_auth.py: update for gnupg 1.4.18 (Closes: #755342)

 -- Brian Murray <email address hidden> Wed, 02 Dec 2015 10:51:58 -0800

[Andy Brody (abrody)]

This also affects vivid, yes? It seems like many people will be running this on vivid as it approaches end of life.

[Svivi (svivi)]

I can confirm that Vivid is still affected.

$ apt-cache policy python-apt
python-apt:
  Telepítve: 0.9.3.11build1
  Jelölt: 0.9.3.11build1
  Verziótáblázat:
 *** 0.9.3.11build1 0
        500 http://ubuntu.mirror.lrz.de/ubuntu/ vivid/main amd64 Packages
        100 /var/lib/dpkg/status

$ ubuntu-support-status
Traceback (most recent call last):
  File "/usr/bin/ubuntu-support-status", line 135, in <module>
    pkg.name, support_tag)
  File "/usr/bin/ubuntu-support-status", line 51, in get_maintenance_status
    raise Exception("No date tag found")
Exception: No date tag found

[Brian Murray (brian-murray)]

Vivid reaches End of Life this month, so I'm not certain it is worth the effort to SRU this there.

[Denis Gubanov (v12aml)]

root@controller:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.4 LTS
Release: 14.04
Codename: trusty
root@controller:~# apt-cache policy python-apt python3-apt update-manager-core
python-apt:
  Installed: 0.9.3.5ubuntu2
  Candidate: 0.9.3.5ubuntu2
  Version table:
 *** 0.9.3.5ubuntu2 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.3.5 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
python3-apt:
  Installed: 0.9.3.5ubuntu2
  Candidate: 0.9.3.5ubuntu2
  Version table:
 *** 0.9.3.5ubuntu2 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.3.5 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
update-manager-core:
  Installed: 1:0.196.14
  Candidate: 1:0.196.14
  Version table:
 *** 1:0.196.14 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:0.196.11 0
        500 http://ru.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
root@controller:~# ubuntu-support-status
Traceback (most recent call last):
  File "/usr/bin/ubuntu-support-status", line 133, in <module>
    pkg.name, support_tag)
  File "/usr/bin/ubuntu-support-status", line 49, in get_maintenance_status
    raise Exception("No date tag found")
Exception: No date tag found
root@controller:~#

[Anthony J Burton (aburton-v)]

This does not appear to be fixed in either Trusty or Wily.

me@a-trusty-system:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.4 LTS
Release: 14.04
Codename: trusty

me@a-trusty-system:~$ apt-cache policy python-apt python3-apt update-manager-core
python-apt:
  Installed: 0.9.3.5ubuntu2
  Candidate: 0.9.3.5ubuntu2
  Version table:
 *** 0.9.3.5ubuntu2 0
        500 http://aptly.optoro.io/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.3.5 0
        500 http://aptly.optoro.io/ubuntu/ trusty/main amd64 Packages
python3-apt:
  Installed: 0.9.3.5ubuntu2
  Candidate: 0.9.3.5ubuntu2
  Version table:
 *** 0.9.3.5ubuntu2 0
        500 http://aptly.optoro.io/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.3.5 0
        500 http://aptly.optoro.io/ubuntu/ trusty/main amd64 Packages
update-manager-core:
  Installed: 1:0.196.14
  Candidate: 1:0.196.14
  Version table:
 *** 1:0.196.14 0
        500 http://aptly.optoro.io/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:0.196.11 0
        500 http://aptly.optoro.io/ubuntu/ trusty/main amd64 Packages

me@a-trusty-system:~$ ubuntu-support-status
Traceback (most recent call last):
  File "/usr/bin/ubuntu-support-status", line 133, in <module>
    pkg.name, support_tag)
  File "/usr/bin/ubuntu-support-status", line 49, in get_maintenance_status
    raise Exception("No date tag found")
Exception: No date tag found

## and on wily

me@a-wily-system:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.10
Release: 15.10
Codename: wily

me@a-wily-system:~$ apt-cache policy python-apt python3-apt update-manager-core
python-apt:
  Installed: 1.0.1build1
  Candidate: 1.0.1build1
  Version table:
 *** 1.0.1build1 0
        500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status
python3-apt:
  Installed: 1.0.1build1
  Candidate: 1.0.1build1
  Version table:
 *** 1.0.1build1 0
        500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status
update-manager-core:
  Installed: 1:15.10.3
  Candidate: 1:15.10.3
  Version table:
 *** 1:15.10.3 0
        500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
        100 /var/lib/dpkg/status

me@a-wily-system:~$ ubuntu-support-status
Traceback (most recent call last):
  File "/usr/bin/ubuntu-support-status", line 135, in <module>
    pkg.name, support_tag)
  File "/usr/bin/ubuntu-support-status", line 51, in get_maintenance_status
    raise Exception("No date tag found")
Exception: No date tag found

[Serhiy Zahoriya (xintx-ua)]

Not fixed in python-apt 0.9.3.5ubuntu2

$ sudo apt install python-apt
...
Get:1 http://mirror.nl.leaseweb.net/ubuntu/ trusty-updates/main python-apt amd64 0.9.3.5ubuntu2 [141 kB]
...
Unpacking python-apt (0.9.3.5ubuntu2) over (0.9.3.5ubuntu1) ...
Setting up python-apt (0.9.3.5ubuntu2) ...
$ ubuntu-support-status
Traceback (most recent call last):
  File "/usr/bin/ubuntu-support-status", line 133, in <module>
    pkg.name, support_tag)
  File "/usr/bin/ubuntu-support-status", line 49, in get_maintenance_status
    raise Exception("No date tag found")
Exception: No date tag found

[Serhiy Zahoriya (xintx-ua)]

Fixed on Trusty after upgrading python3-apt