Re: RFS: python3-dateutil
* Thomas Kluyver <thomas@kluyver.me.uk>, 2012-03-24, 12:29:
"debhelper (>= 8)" instead of "debhelper (>= 8.0.0)" would be more
friendly to backporters.
Done. Note this is what the file created by dh_make has (although that
could have been updated in a newer version than I have).
I don't accept "it's dh_make's fault!" excuses, sorry. :P
The stand-alone license paragraph in the copyright file is not
properly formatted. The same rules as for the long description in
debian/control are used for this field. Please see Policy §5.6.13 for
details.
I've added an extra space before the numbered section so it won't be
word-wrapped. Is there another problem?
It looks good now.
What is the license of zoneinfo-2011d.tar.gz ?
The packaging deletes it, so I'd assumed it doesn't need license
information. Upstream doesn't mention anything specific, and looking at
python-dateutil, there's no license information for it there either.
As Geoffroy said in other mail, it doesn't matter that the file it not
included in the binary package.
Apart from the fact the license and copyright status of the file is not
documented in debian/copyright, there's another problem: the tarball
appears to be a collection of binary blobs, for which we have no source.
I'm afraid that you'll have to either ask upstream to include the
actual source for zoneinfo or repack the source.
Please run tests for all supported Python 3 versions, not only for the
default one.
Done.
Now please honour Policy §4.6. :)
BTW, is there a reason you use "set -ex" in override_dh_auto_install but
only "set -e" in override_dh_auto_build? I'd prefer more consistency. :)
The watch file doesn't work:
Done (Copied from python-dateutil)
I can't say I'm happy about the amount of cruft in this watch, but at
least it works…
Has the Use-C-locale-when-calling-date patch been forwarded upstream?
No - it was made in python-dateutil and apparently not forwarded.
Upstream's version is cross-platform (Windows has a date command), so I
guess it's not something the whole package would want.
All right.
dateutil.zoneinfo.gettz() always returns None. Is that how it's
supposed to work?
I think this is a consequence of our removing the zoneinfo data file.
It should probably be patched to use a system copy, but python-dateutil
seems to live without that functionality.
There is also dateutil.tz.gettz(), which is supposed to use the
system timezone database, but it doesn't work either:
| >>> dateutil.tz.gettz('Europe/Warsaw') is None
| True
Trying to open the file directly reveals the actual error:
| >>> dateutil.tz.tzfile('/usr/share/zoneinfo/Europe/Warsaw')
| Traceback (most recent call last):
| File "<stdin>", line 1, in <module>
| File "/usr/lib/python3/dist-packages/dateutil/tz.py", line 215, in __init__
| if fileobj.read(4).decode() != "TZif":
| File "/usr/lib/python3.2/codecs.py", line 300, in decode
| (result, consumed) = self._buffer_decode(data, self.errors, final)
| UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa7 in position 35: invalid start byte
--
Jakub Wilk
Reply to: