Re: RFS: python3-dateutil

2012-03-24 Thread Thomas Kluyver
On 24 March 2012 22:41, Jakub Wilk 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

Re: RFS: python3-dateutil

2012-03-24 Thread Ben Finney
Jakub Wilk writes: > * Thomas Kluyver , 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).

Re: RFS: python3-dateutil

2012-03-24 Thread Jakub Wilk
* Thomas Kluyver , 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

Re: RFS: python3-dateutil

2012-03-24 Thread Thomas Kluyver
On 24 March 2012 21:21, Ben Finney wrote: > That's what makes the most sense to me. Some DDs don't like it, some > prefer it, and most will (IME) not mind very much either way. > > My advice: Do what you've done, and see what the particular sponsor > prefers. Thanks, Ben. I've reverted it to 2.0-

Re: RFS: python3-dateutil

2012-03-24 Thread Ben Finney
Thomas Kluyver writes: > On 24 March 2012 10:59, Jakub Wilk wrote: > > Please merge the two changelog entries. > > Done. I thought I should bump the number if I'd published the package > anywhere, evidently I was wrong about that. That's what makes the most sense to me. Some DDs don't like it,

Re: RFS: python3-dateutil

2012-03-24 Thread Thomas Kluyver
On 24 March 2012 13:16, Geoffroy Youri Berret wrote: > In the worse case (non dfsg licence) you need to repack upstream to have > a dfsg suffixed package. I think it's just a tarball of the same data that's in the tzdata package - in which case, it's public domain. I'll add it as a section in the

Re: RFS: python3-dateutil

2012-03-24 Thread Geoffroy Youri Berret
Le 24/03/2012 13:29, Thomas Kluyver a écrit : >> 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 th

Re: RFS: python3-dateutil

2012-03-24 Thread Thomas Kluyver
Thanks Jakub and Geoffroy, (below, Done = changes committed to SVN. I'll reupload to mentors shortly) On 24 March 2012 10:59, Jakub Wilk wrote: > Please merge the two changelog entries. Done. I thought I should bump the number if I'd published the package anywhere, evidently I was wrong about t

Re: RFS: python3-dateutil

2012-03-24 Thread Geoffroy Youri Berret
Hi Thomas, I'm not a DD, therefore I cannot sponsor your package, here is my review nonetheless. Le 24/03/2012 03:39, Thomas Kluyver a écrit : > Hi all, >[…] > > Package name: python3-dateutil > Version : 2.0-2 > Upstream Author : Gustavo Niemeyer > URL : http://labix.o

Re: RFS: python3-dateutil

2012-03-24 Thread Jakub Wilk
Please merge the two changelog entries. "debhelper (>= 8)" instead of "debhelper (>= 8.0.0)" would be more friendly to backporters. Please add Vcs-* fields (and remove the commented-out ones, sigh...). s/monday/Monday/ in the package description. Lintian emits: P: python3-dateutil source: un