Re: RFS: python3-dateutil

2012-04-18 Thread Thomas Kluyver
On 18 April 2012 18:03, Jakub Wilk wrote: > But anyway, I bumped timestamp in the changelog, built, signed and uploaded > the package. Thanks. Thanks Jakub, and thanks for taking the time to go through all these things with me. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.de

Re: RFS: python3-dateutil

2012-04-18 Thread Jakub Wilk
There are some warnings while running tests: build/lib/dateutil/tz.py:910: ResourceWarning: unclosed file <_io.BufferedReader name='/usr/share/zoneinfo/EST5EDT'> build/lib/dateutil/tz.py:910: ResourceWarning: unclosed file <_io.BufferedReader name='/usr/share/zoneinfo/UTC'> build/lib/dateutil/t

Re: RFS: python3-dateutil

2012-04-17 Thread Thomas Kluyver
On 16 April 2012 21:30, Jakub Wilk wrote: > The extended description is supposed to make sense even when it's displayed > alone, without the synposis. So it certainly cannot start with “It > features:”. Done. I'd misunderstood the format, I thought that it was simply continuation of the field on

Re: RFS: python3-dateutil

2012-04-16 Thread Jakub Wilk
The extended description is supposed to make sense even when it's displayed alone, without the synposis. So it certainly cannot start with “It features:”. See also: * Debian Policy §3.4.2 * Developer's Reference §6.2.3 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.deb

Re: RFS: python3-dateutil

2012-04-14 Thread Thomas Kluyver
On 14 April 2012 11:12, Jakub Wilk wrote: > Could you update the latter item? Yep, done. 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/caovn4qi4hvyeg2dqa

Re: RFS: python3-dateutil

2012-04-14 Thread Jakub Wilk
* Thomas Kluyver , 2012-04-02, 21:41: Wouldn't it be better to update zoneinfo.gettz() tests to use tz.gettz(), instead of disabling them entirely? [...] All done. Thanks. But the changelog still reads: * Repackage source without binary parts * Remove tests that fail without said parts Could

Re: RFS: python3-dateutil

2012-04-10 Thread Thomas Kluyver
On 5 April 2012 11:38, Jakub Wilk wrote: > Indeed, adding --check-dirname-level=0 fixes the problem for me. I've added that, and checked that it still works for me. Thanks, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Cont

Re: RFS: python3-dateutil

2012-04-05 Thread Jakub Wilk
* Thomas Kluyver , 2012-04-04, 22:28: $ uscan --version This is uscan, from the Debian devscripts package, version 2.11.6ubuntu1 $ uscan --version | head -n1 This is uscan, from the Debian devscripts package, version 2.11.6 I don't see any relavant changes in the Ubuntu changelog. So I added

Re: RFS: python3-dateutil

2012-04-04 Thread Thomas Kluyver
On 4 April 2012 22:14, Jakub Wilk wrote: > Hmm, didn't help here: No bright ideas. What uscan version do you have? $ uscan --version This is uscan, from the Debian devscripts package, version 2.11.6ubuntu1 > I took a closer look at your watch file: I've followed all of your suggestions, and ch

Re: RFS: python3-dateutil

2012-04-04 Thread Jakub Wilk
* Thomas Kluyver , 2012-04-03, 20:57: Your get-orig-source target tries to support being invoked from any directory, but this doesn't work: You're right. I've used `pwd` now instead of . and it appears to work. Hmm, didn't help here: $ ../trunk/debian/rules get-orig-source py3versions: error

Re: RFS: python3-dateutil

2012-04-03 Thread Thomas Kluyver
On 2 April 2012 23:23, Jakub Wilk wrote: > Your get-orig-source target tries to support being invoked from any > directory, but this doesn't work: You're right. I've used `pwd` now instead of . and it appears to work. I was following the example here: https://wiki.ubuntu.com/PackagingGuide/Exampl

Re: RFS: python3-dateutil

2012-04-02 Thread Jakub Wilk
* Thomas Kluyver , 2012-04-02, 21:41: Please add get-orig-source target. [...] All done. Your get-orig-source target tries to support being invoked from any directory, but this doesn't work: $ ../trunk/debian/rules get-orig-source py3versions: error parsing Python-Version attribute uscan

Re: RFS: python3-dateutil

2012-04-02 Thread Jakub Wilk
* Thomas Kluyver , 2012-04-02, 21:41: I seem to have locked the package out of mentors.debian.net; I'll try uploading it again tomorrow. No worries, I get the source from svn repository anyway. I suspect that most (all?) other people who would be interested in the package prefer that way over

Re: RFS: python3-dateutil

2012-04-02 Thread Thomas Kluyver
On 1 April 2012 10:53, Jakub Wilk wrote: > Wouldn't it be better to update zoneinfo.gettz() tests to use tz.gettz(), > instead of disabling them entirely? > > Please add get-orig-source target. > > The copyright file mentions dateutil/zoneinfo/zoneinfo-2011d.tar.gz, which > doesn't exist in .orig.

Re: RFS: python3-dateutil

2012-04-01 Thread Jakub Wilk
* Thomas Kluyver , 2012-03-28, 22:33: As far as I can see, the zoneinfo subpackage is used as a fallback by dateutil.tz.gettz() if it can't find the equivalent system timezone data files (the binary package has a dependency on tzdata). zoneinfo.gettz() appears to account for the possibility th

Re: RFS: python3-dateutil

2012-03-28 Thread Thomas Kluyver
On 28 March 2012 21:10, Jakub Wilk wrote: > I see that you disabled tests for zoneinfo, which I interpret as a "yes" > answer to my question. Well, I can't see how such behaviour is useful[0], > but at very least it deserves a big red warning in README.Debian. As far as I can see, the zoneinfo su

Re: RFS: python3-dateutil

2012-03-28 Thread Jakub Wilk
* Thomas Kluyver , 2012-03-24, 12:29: 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 functi

Re: RFS: python3-dateutil

2012-03-28 Thread Thomas Kluyver
On 26 March 2012 21:28, Jakub Wilk wrote: >>> 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

Re: RFS: python3-dateutil

2012-03-26 Thread Jakub Wilk
* Thomas Kluyver , 2012-03-25, 00:38: 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

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