Your message dated Sat, 20 Apr 2019 17:51:38 +0200 with message-id <[email protected]> and subject line Re: Bug#913205: python-urllib3: mythtv ttvdb.py fails with latest python-urllib3 has caused the Debian Bug report #913205, regarding python-urllib3: mythtv ttvdb.py fails with latest python-urllib3 to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 913205: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913205 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: python-urllib3 Version: 1.24-1 Severity: important Mythtv version 29.1+fixes20180821.gite5fc66e822-dmo2 is failing with mythtv@vito:~$ /usr/share/mythtv/metadata/Television/ttvdb.py -B Superstore Traceback (most recent call last): File "/usr/share/mythtv/metadata/Television/ttvdb.py", line 2578, in <module> sys.exit(main()) File "/usr/share/mythtv/metadata/Television/ttvdb.py", line 2278, in main userkey=tvdb_account.account_identifier) File "/usr/lib/python2.7/dist-packages/MythTV/ttvdb/tvdb_api.py", line 693, in __init__ self.session.remove_expired_responses() File "/usr/lib/python2.7/dist-packages/requests_cache/core.py", line 159, in remove_expired_responses self.cache.remove_old_entries(datetime.utcnow() - self._cache_expire_after) File "/usr/lib/python2.7/dist-packages/requests_cache/backends/base.py", line 110, in remove_old_entries response, created_at = self.responses[key] File "/usr/lib/python2.7/dist-packages/requests_cache/backends/storage/dbdict.py", line 163, in __getitem__ return pickle.loads(bytes(super(DbPickleDict, self).__getitem__(key))) ImportError: No module named ordered_dict Meaning that mythtv can no longer pick up programme information from thetvdb.org Falling back to version 1.22-1 makes everything work again. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-urllib3 depends on: ii python 2.7.15-3 ii python-six 1.11.0-2 Versions of packages python-urllib3 recommends: ii ca-certificates 20170717 ii python-cryptography 2.3-1 ii python-idna 2.6-1 ii python-ipaddress 1.0.17-1 ii python-openssl 18.0.0-1 Versions of packages python-urllib3 suggests: pn python-ntlm <none> pn python-socks <none> -- no debconf information
--- End Message ---
--- Begin Message ---Hello James, On 11/8/18 11:51 PM, James Bottomley wrote: > Yes, removing the cache directory seems to allow it to work again. Glad to hear this! > It's not the only bug report, though. The internet has quite a few of > them; that's how I (eventually) figured out that the version change > from 1.22 to 1.24 of urllib3 was the problem. But as you discovered the problem is not in urllib3 itself, since removing the cache fix the problem. > Well, the usual assumption people work under is that upgrading minor > versions doesn't break stuff ... that means you should be able to > upgrade from 1.22 to 1.24 without issue. We can't assume this, usually this is true for the minor point release number (so when the third number change), but it depends on authors to follow this rule. > That, unfortunately, doesn't seem to be true for urllib3 as the trace dump > show. The problem here is more complex than this, I mean it's in the interaction between the various actors involved. If I have to point to the most offender, I would point to picke module. :) A marshalling mechanism that doesn't involve the notion of Python object would not depends on specific modules being present or not. > I suspect the only way you're going to find out is by bug reports like this > one. For software not in Debian yes, that's the only way. For software in Debian we have CI tests that could catch this: I say could because in this specific case mythtv should have a test for the scenario that showed up: using a cache that depends on the notion of Python objects (picke) and change the "format" of this Python object. The problem here is due multiple factors... mainly using picke as a caching mechanism is more fragile that other way of caching. > So now you know and you think you have a cause, is there a way to prevent > other people seeing the same issue? Not from urllib3 side. One thing that could be done is on mythtv side. I would ask to mythtv developers if they have the time to handle caching in a more robust way: from the traceback you attached the problem appeared when mythtv tried to call self.session.remove_expired_responses(): why not catch exceptions and handle them based on the severity? I mean if the cache can't be used it's safe to delete it entirely. This way the users would not even notice the issue we are talking about here. Regards, P.S. I'm closing this bug since there is nothing to do on urllib3 side, thanks for your report. -- Daniele Tricoli 'eriol' https://mornie.org
--- End Message ---
_______________________________________________ Python-modules-team mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
