On Sep 08, 2011, at 11:37 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2011-09-08]
>> >* build directory is not removed in clean target (and thus package
>> > cannot be build twice in a row)
>
>this one is fixed, but now I get changes in SOURCES.txt which
>includes... .txt files in debian/python-flufl.lock/usr/lib/python2.7
>(due to "global-include *.txt" in MANIFEST.in)
I think this is because ./flufl.lock.egg-info hangs around between the two
builds. Explicitly rm'ing this fixes the issue for me
>> This is because dh_auto_clean does not remove the build/sphinx directories.
>> Adding an override_dh_auto_clean target which `rm -rf build/sphinx` does
>> the trick. However, I wonder if this is something that `--with sphinxdoc`
>> should help with? If so, I'm willing to at least file a bug.
>
>If that's the standard build directory for Sphinx, then sure, --with
>sphinxdoc could remove it; ping Jakub about it
I've submitted a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641050
This could also be related to Debian bug 618367 (see below).
>> >E: python-flufl.lock: helper-templates-in-copyright
>>
>> Okay, I removed the "(s)" but this one seems bogus for several reasons.
>> First, the lintian warning really doesn't tell you what's wrong with your
>> debian/copyright file, so you're left to guessin' 'n googlin'. Second,
>> debbug #631674.
>
>wasn't 631674 fixed a month ago?
That's what I thought too, so I don't understand why it's still complaining
about it. OTOH, it's easier just to remove the suffix.
>BTW, you did invoke lintian with -i option
>(or `lintian-info --tags helper-templates-in-copyright`),
>right? It's a little bit more verbose.
Nope, but thanks for the tip!
>[...]
>> >W: python-flufl.lock: duplicate-changelog-files
>> >usr/share/doc/python-flufl.lock/changelog.gz
>> >usr/share/doc/python-flufl.lock/html/_sources/NEWS.txt.gz
>>
>> I'm not getting this one now. Maybe it's due to the other changes I'm about
>> to commit. Please let me know if you still get this.
>
>yep, NEWS.txt.gz is now a symlink to changelog.gz
>thanks to dh_installchangelogs' "-k flufl/lock/NEWS.txt" option in your
>debian/rules
I'm still not getting this one, so I don't know what to do about it.
>new problems (or the ones I missed last time):
>* documentation files (*.txt *and* conf.py file) are now in dist-packages
I think that's fine. All the flufl.* packages have both unittests and
doctests. The doctests are in the .txt files, but they have to be accessible
via sys.path, which answers your question below. flufl.lock.docs must be a
package directory, but the only .py file it contains is __init__.py. I
personally want to include the test suite in the package, and anyway it
doesn't add anything appreciable to the size of the package.
The conf.py file is used to generate the Sphinx docs from the doctests. I
don't see any value in just leaving it there; it doesn't collide with anything
else.
>* both flufl.lock-2.1.1.egg-info and flufl.lock.egg-info files are
> installed - get rid of one of them
I think this is an artifact of Debian bug #618367. Since I think the egg-info
with the version number is intended, I'll remove the unversioned one. Here's
the hack for that, though it's ugly:
override_dh_auto_install:
dh_auto_install
# Debian bug #618367
rm -rf debian/*/usr/lib/python*/*-packages/flufl.lock.egg-info
>* flufl.lock-2.1.1-nspkg.pth is not really needed (I think I will add an
> option to dh_python2 to remove .pth files, I cannot do that by
> default, though)
This is an artifact of `python setup.py install-egg-info`. Is it harmful to
leave it there? Personally I don't care about it.
>* what's the purpose of empty flufl.lock.docs module (and using.txt in
> the directory with __init__.py)?
See above.
>[...]
>> >PS feel free to reply in private
>>
>> Thanks. I hope you don't mind me replying publicly
>
>not at all. It's just that people ask more questions in private and I prefer
>questions rather than "hiding" problems (if you will not ask, I might
>miss it). Please don't CC me if you reply to a mailing list that I'm
>subscribed, though. TIA
No problem. Your messages include the List-Post: header and I use a sane MUA
with a reply-to-list function. :)
>[...]
>> Anyway, thanks for the great feedback, and apologies for taking so long to
>> respond.
>
>it's not a record at all, I'm still waiting for a response to my
>"libc/ctypes problem" reply to one of sponsorees from... 9th May 2009 -
>my Debian/RFS contains lots of threads waiting for sponsorees (and in
>few seconds: none waiting for me, yey! :)
I'm sure there are people who still expect a response from some random Mailman
email they sent me 10 years ago.
/me-tries-again-to-boot-up-his-clone-army-ly y'rs,
-Barry
Attachment:
signature.asc
Description: PGP signature