Re: RFS: python3-dateutil
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/tz.py:910: ResourceWarning: unclosed file _io.BufferedReader name='/usr/share/zoneinfo/America/New_York' Please consider running tests with --verbose, because currently build log becomes unreadable if warnings are emitted But anyway, I bumped timestamp in the changelog, built, signed and uploaded the package. Thanks. -- Jakub Wilk -- 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/20120418170347.gb3...@jwilk.net
Re: RFS: python3-dateutil
On 18 April 2012 18:03, Jakub Wilk jw...@debian.org 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.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caovn4qhxk6ngw-dp+djxwcwysuxcxzycqkanmwdynt73jon...@mail.gmail.com
Re: RFS: python3-dateutil
On 16 April 2012 21:30, Jakub Wilk jw...@debian.org 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 the line Description: . 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/caovn4qjbsri7252nxhymqk_ehdsny9bsdgcaavr7scmzzkg...@mail.gmail.com
Re: RFS: python3-dateutil
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.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120416203017.ga5...@jwilk.net
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 you update the latter item? -- Jakub Wilk -- 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/20120414101229.ga2...@jwilk.net
Re: RFS: python3-dateutil
On 14 April 2012 11:12, Jakub Wilk jw...@debian.org 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/caovn4qi4hvyeg2dqa9qer10nxay9ennotf254rtwjhp52dm...@mail.gmail.com
Re: RFS: python3-dateutil
On 5 April 2012 11:38, Jakub Wilk jw...@debian.org 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? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOvn4qiGDkeeNvH_n_z3hm61iC4nvV06smxEaR9Z6U=srcq...@mail.gmail.com
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 --verbose to the uscan call, which revealed what the problem is: $ ../trunk/debian/rules get-orig-source py3versions: error parsing Python-Version attribute uscan --noconf --force-download --rename --download-current-version --destdir=`pwd` ../trunk/debian//.. --verbose -- Scanning for watchfiles in ../trunk/debian//.. -- Skip watchfile in ../trunk/debian//../debian since it does not match the package name (or the settings of the --check-dirname-level and --check-dirname-regex options if any). -- Scan finished make: *** [get-orig-source] Error 1 Indeed, adding --check-dirname-level=0 fixes the problem for me. -- Jakub Wilk -- 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/20120405103847.ga1...@jwilk.net
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 parsing Python-Version attribute uscan --noconf --force-download --rename --download-current-version --destdir=`pwd` ../trunk/debian//.. make: *** [get-orig-source] Error 1 I took a closer look at your watch file: uversionmangle=s/\.(tar.*|tgz|zip|gz|bz2)$//i - why put this stuff to upstream version in the first place? [*] dversionmangle=s/[-.+~]?(cvs|svn|git|snapshot|pre|hg|dfsg)(.*)$//i - stripping dfsg is correct, but stripping cvs, svn etc. parts is wrong. dversionmangle is supposed to map Debian version to upstream version. But if you packaged a VCS snapshot, then no upstream version corresponding to Debian version exist. Stripping pre (or more generally: ~something) is even worse, because it's fooling uscan into thinking that Debian version is newer than it actually is. pasv - this makes no sense for HTTP. (Even for FTP, I don't believe there's much point in putting this option to debian/watch.) -?_? - this should have probably been [-_]. ([\d+\.]+|\d+) is equivalent to much simpler ([\d+.]+). Though maybe you actually meant ((\d+\.)+|\d+), which is something different. (tar.*|tgz|zip|gz|bz2|) - you should use non-capturing (?:...) here to fix [*]. Also, I don't see any point in keeping gz, bz2 or an empty string in the alternative. -- Jakub Wilk -- 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/20120404211405.ga...@jwilk.net
Re: RFS: python3-dateutil
On 4 April 2012 22:14, Jakub Wilk jw...@debian.org 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 checked that it still works. Previously, I'd just copied the watch file from python-dateutil; evidently it wasn't as good an example as I had hoped. 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/caovn4qiv6bw0syaqcgkfwi4e5zd4ajos3x+wcrblhocksyr...@mail.gmail.com
Re: RFS: python3-dateutil
On 2 April 2012 23:23, Jakub Wilk jw...@debian.org 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/Examples/ChangingTheOrigTarball Please merge changelog entries for 2.0+dfsg1-1 and 2.0-1. 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/caovn4qhgem+yzrpgwbym2sneccbdcobdpilv4racmm9qu4x...@mail.gmail.com
Re: RFS: python3-dateutil
On 1 April 2012 10:53, Jakub Wilk jw...@debian.org 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.tar anymore. All done. I seem to have locked the package out of mentors.debian.net; I'll try uploading it again tomorrow. 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/caovn4qiaxbcclkw832h9-rgb92h2te0tr_vd6sngxnnr2d4...@mail.gmail.com
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 dget'ing stuff from mentors, too. -- Jakub Wilk -- 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/20120402213631.ga5...@jwilk.net
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 --noconf --force-download --rename --download-current-version --destdir=. ../trunk/debian//.. make: *** [get-orig-source] Error 1 (I'm not sure I understand what happened here. Maybe it's a bug in uscan?) Please merge changelog entries for 2.0+dfsg1-1 and 2.0-1. -- Jakub Wilk -- 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/2012040334.ga6...@jwilk.net
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 that its local data file doesn't exist, and returns None. I'm inclined to leave this behaviour intact in case code depends on it, although it's not how I'd design it myself. I've added a note in README.Debian pointing people to dateutil.tz.gettz(). Okay... 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.tar anymore. -- Jakub Wilk -- 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/20120401095349.ga9...@jwilk.net
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 functionality. 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. [0] Useful behaviour would be e.g.: - using system-wide timezone database or - throwing an exception (with an informative message) if user tries to use the function or even - not shipping the sub-module at all in the binary package. -- Jakub Wilk -- 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/20120328201010.ga1...@jwilk.net
Re: RFS: python3-dateutil
On 28 March 2012 21:10, Jakub Wilk jw...@debian.org 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 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 that its local data file doesn't exist, and returns None. I'm inclined to leave this behaviour intact in case code depends on it, although it's not how I'd design it myself. I've added a note in README.Debian pointing people to dateutil.tz.gettz(). 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/CAOvn4qie-yBr-novh71RXNY-_Qd=W3dz24nw2u2+nML+B_4O=g...@mail.gmail.com
Re: RFS: python3-dateutil
* Thomas Kluyver tho...@kluyver.me.uk, 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 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? I believe so. 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. Well, ftp-masters aren't infallible. I've just filed RC bug against python-dateutils: http://bugs.debian.org/665894 I wonder if bug #597098 should be merged with your ITP. -- Jakub Wilk -- 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/20120326202816.ga...@jwilk.net
