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'
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
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 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
* 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
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:
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.
* 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
* 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
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
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:
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
* 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
* 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
* 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
* 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
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
* 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
18 matches
Mail list logo
