On 24 March 2012 22:41, Jakub Wilk <jw...@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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caovn4qgqwbdt0vrt0whnyopvxc-fojqo-l3mynrxtrcr_fd...@mail.gmail.com