Re: RFS: python3-dateutil

[Thomas Kluyver <thomas@kluyver.me.uk>]

On 24 March 2012 22:41, Jakub Wilk <jwilk@debian.org> wrote:
> I don't accept "it's dh_make's fault!" excuses, sorry. :P

I'm not aiming to make excuses - I'm suggesting that dh_make could be
updated to produce the preferred style of output, if that hasn't
already happened. I see Ben's just phrased this better than I can.

> 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.

I know Debian is stringent about these things, but is this really
necessary? We're not even using the file, and upstream says where the
files are from (see
http://labix.org/python-dateutil#head-7b64fa6ed6e02b68e9cb7c3d42d6fb7b4cb133e9).
The Python 2 version has already been accepted in Debian with an
equivalent (slightly older) file.

> Now please honour Policy §4.6. :)

Done, in that I've added 'set -e' before the loop.

> 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. :)

I've standardised them on 'set -e'.

> There is also dateutil.tz.gettz(), which is supposed to use the system
> timezone database, but it doesn't work either:

I'll look into fixing this.

Thanks,
Thomas